Since the range of two's complement integers is asymmetric >> + * with one additional negative value (JLS {@jls 4.2.1}), the >> + * mathematical absolute value of {@link Integer#MIN_VALUE} >> + * overflows the positive {@code int} range, so an exception is >> + * thrown for that argument. >> + * >> + * @param a the argument whose absolute value is to be determined >> + * @return the absolute value of the argument, unless overflow occurs >> + * @throws ArithmeticException if the argument is {@link >> Integer#MIN_VALUE} >> + * @see Math#abs(int) >> + * @since 15 >> + */ >> + public static int absExact(int a) { >> + if (a == Integer.MIN_VALUE) >> + throw new ArithmeticException( >> + "Overflow to represent absolute value of >> Integer.MIN_VALUE"); >> + else >> + return abs(a); >> + } >> >> For the StrictMath methods, I include links to the Math equivalent, as >> the other fooExact StrictMath methods do. >> >> Thanks, >> >> -Joe >> >> >> On 3/30/2020 9:31 AM, Joe Darcy wrote: >>> Hi Brian and Chris, >>> >>> I was considering adding such as JLS link myself; I'll work one in and >>> post a revised webrev. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 3/30/2020 9:29 AM, Brian Burkhalter wrote: >>>> Hi Joe, >>>> >>>>> On Mar 30, 2020, at 6:31 AM, Chris Hegarty >>>> > wrote: >>>>> >>>>>> Full webrev for review include including tests: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/8241374.0/ >>>>>> >>>>>> and the companion CSR: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241805 >>>>> Looks good to me. >>>> Likewise. >>>> >>>>> I do like the explanatory paragraph about the asymmetry in the range >>>>> of two's complement integer values. An alternative, or addition, >>>>> would be a link to JLS 4.2.1 - Integral Types and Values [1], which >>>>> shows the asymmetry from a language perspective. >>>> I also like this suggestion. >>>> >>>> Brian >>>> >>>>> -Chris. >>>>> >>>>> [1]https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.2.1 From denghui.ddh at alibaba-inc.com Wed Apr 1 02:51:41 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 01 Apr 2020 10:51:41 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIzODY2NTogQWRkIEpGUiBldmVudCBmb3IgZGlyZWN0IG1lbW9yeSBzdGF0?= =?UTF-8?B?aXN0aWNz?= In-Reply-To: <71F22B86-2175-4E40-AFE6-A2F16D63ACB1@oracle.com> References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <57694371-7665-8b03-5c73-48f641b92290@oracle.com> <31b99e24-74d4-47c9-a37b-875aa87ad7db.denghui.ddh@alibaba-inc.com> <42408a13-f123-479c-dcf3-240bfc0f8f3d@oracle.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> , <71F22B86-2175-4E40-AFE6-A2F16D63ACB1@oracle.com> Message-ID: Thanks! Please help sponsor it if there is no other problem. jdk/jfr and java/lang/management all passed in my Linux env. Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?4?1?(???) 01:01 To:???(??) Cc:Alan Bateman ; hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Looks good. Erik On 31 Mar 2020, at 18:22, Denghui Dong wrote: Hi Erik, IMO, one event type per pool is a better choice, because: 1. easy filtering and configuration as you said, and I don't think there will be too many buffer pool types in the future 2. some buffer pools may have extra fields, e.g. direct memory has max capacity limit. webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.05/ diff with webrev.04: http://cr.openjdk.java.net/~ddong/8238665/v4-v5.diff please review it, thanks! Denghui Dong ------------------------------------------------------------------ From:Erik Gahlin Send Time:2020?3?31?(???) 19:18 To:???(??) Cc:Alan Bateman ; hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi Denghui, I think there should be one event type per pool, or there should be a text field specifying which pool it is. If we believe there will be many pools in the future, it may make sense for a field, otherwise I think an event type could be used. The benefit of one event type per pool is that there can be a description per pool and it also allows easy filtering and configuration. If there would be four pools, they could all derive from an abstract event class and only add @Label and @Description per event subclass. If there would be forty pools, it would be too much noise and a field would be better. Erik On 31 Mar 2020, at 11:06, Denghui Dong wrote: PING. @Erik Could you review it? Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2020?3?19?(???) 16:35 To:Alan Bateman ; Erik Gahlin Cc:hotspot-jfr-dev ; core-libs-dev Subject:Re: RFR: 8238665: Add JFR event for direct memory statistics Hi, On Mar 18, 2020, at 11:46 PM, Alan Bateman wrote: On 13/03/2020 14:54, Denghui Dong wrote: Good suggestion, moved. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.03/ This looks much better. What would you think about renaming the JFR event to "DirectBufferStatistics"? The concern I have with the proposed naming is that it will be really awkward to extend it to support mapped buffers. It?s ok for me. The implementation changes look okay, hopefully Erik will skim over them. One small suggestion for for ManagementFactoryHelper is that you can stream().collect(Collectors.toList()) to create the value for bufferPools. You could even change it to volatile so that getBufferMXBeans isn't a synchronized method. Make sense, updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.04/ @Erik, could you help review it? -Alan. Denghui Dong From mandy.chung at oracle.com Wed Apr 1 03:01:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 20:01:10 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Thanks to the review feedbacks. Updated webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ Delta between webrev.03 and webrev.04: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ Summary of changes is: 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate 2. Rename Class::isHiddenClass to Class::isHidden 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes 4. Add test case for unloadable class with nest host error 5. Add test cases for hidden classes with different kinds of class or interface 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" 7. Small changes in response to Remi, Coleen, Paul's review comments 8. Fix copyright headers 9. Fix @modules in tests Most of the changes above have also been reviewed as separate patches. Thanks Mandy On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From linzang at tencent.com Wed Apr 1 04:55:40 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Wed, 1 Apr 2020 04:55:40 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> Message-ID: <73D63A28-1FA2-45E8-BA34-17E2609C705D@tencent.com> Thanks Henry, I agree to leave Solaris as it is, it seems to me there is no strong reason to remove it. So, Do I need more review before push this patch? And may I ask your help to push it if a go decision is made. Thanks. BRs, Lin ?On 2020/3/31, 12:30 PM, "Henry Jen" wrote: OK, I agree with David gettimeofday is an improvement than 1, so we can go ahead with the patch. Not sure if the caveat should be disclosed or not, I don?t think it?s important enough, just a known fact probably worth to leave a trace(perhaps a comment in code or the bug entry). As whether to change the ifdef to simply detect Solaris, I prefer just to leave it as is for two reasons: 1. It?s not broken, why change it? 2. I checked the code, it?s just a simply macro defined by the make file. Realtime Linux extension would have that function and special custom build can still use that, even though that probably is not happening. Cheers, Henry > On Mar 30, 2020, at 7:39 PM, linzang(??) wrote: > > Hi David, Henry, Alan, > Thanks a lot for your review. > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. > > BRs, > Lin > > >On 2020/3/31, 8:05 AM, "David Holmes" wrote: >> >> On 31/03/2020 4:08 am, Henry Jen wrote: >>> Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use >>> >>> clock_gettime(CLOCK_MONOTONIC_RAW, ts); >>> >>> which I checked seems to be available on both Linux and Mac. Haven?t test it though. >> >> Not guaranteed to be available - either clock_gettime function or that >> particular clock - at build time or runtime. We use a check in the build >> system to determine build-time availability for hotspot, and then use >> dl_lookup etc at runtime to determine if actually available. We should >> be able to get rid of this one day but we checked fairly recently and >> there were still some issues. > >> gettimeofday is a lot better than returning 1. Otherwise call into the >> VM and use JVM_NanoTime. >> >> Cheers, >> David >> ----- >> >>> Cheers, >>> Henry >>> >>>> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >>>> >>>> On 30/03/2020 03:41, linzang(??) wrote: >>>>> Dear All, >>>>> May I ask your help to reivew this tiny patch? Thanks. >>>>> >>>>> >>>>> >>>>> BRs, >>>>> Lin >>>>> >>>>> From: "linzang(??)" >>>>> Date: Thursday, March 26, 2020 at 3:13 PM >>>>> To: "core-libs-dev at openjdk.java.net" >>>>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >>>>> >>>>> Dear All, >>>>> May I ask your help to review this tiny fix? >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >>>>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >>>>> Thanks! >>>>> >>>> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? >>>> >>>> -Alan >>> > > > From Alan.Bateman at oracle.com Wed Apr 1 14:26:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 15:26:08 +0100 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 31/03/2020 20:25, Mandy Chung wrote: > Alex's feedback:? rename isHiddenClass to isHidden as it can be a > hidden class or interface. > > `isLocalClass` and `sAnonymousClass` are correct because the Java > language only has local classes and anon classes, not local interfaces > or anon. interfaces.? `isHidden` is like `isSynthetic`, it could be a > class or interface. > > Although isHiddenClass seems clearer, I'm okay to rename it to > `isHidden`. I went through the java.base changes in webrev.03-delta. The rename to isHidden and the updated javadoc looks good. There are a few additional drive-by updates to the javadoc, including isSynthetic, they all look good too. Maybe I missed it going by, but why is the isHidden check in the field offset methods on sun.misc.Unsafe rather than the internal Unsafe? -Alan. From Alan.Bateman at oracle.com Wed Apr 1 14:43:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 15:43:08 +0100 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> Message-ID: On 31/03/2020 17:22, Denghui Dong wrote: > Hi Erik, > > IMO,?one?event?type?per?pool?is?a?better?choice,?because: > 1.?easy?filtering?and?configuration?as?you?said,?and?I?don't?think?there?will?be?too?many?buffer?pool?types?in?the?future > 2.?some?buffer?pools?may?have?extra?fields,?e.g.?direct?memory?has?max?capacity?limit. > > webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.05/ > diff with webrev.04: http://cr.openjdk.java.net/~ddong/8238665/v4-v5.diff > > This update looks good to me too. Erik, are you okay to sponsor this one? From Alan.Bateman at oracle.com Wed Apr 1 14:45:42 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 15:45:42 +0100 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> Message-ID: <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> On 31/03/2020 19:57, Langer, Christoph wrote: > Hi Mandy, > > this is a good suggestion. The listing of system properties at the props field declaration seems somewhat redundant, given that it already exists more exactly and with API normativity in the doc of System::getProperties(). > > So what do you think of this version: http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ? > Mandy's suggestion to link to getProperties instead is good. This version looks good to me. -Alan. From erik.gahlin at oracle.com Wed Apr 1 14:46:26 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 1 Apr 2020 16:46:26 +0200 Subject: RFR: 8238665: Add JFR event for direct memory statistics In-Reply-To: References: <1a5551a6-645a-490b-98c9-14a65ff5b7a9.denghui.ddh@alibaba-inc.com> <3679e57e-dadb-4b85-80f6-7941376852af.denghui.ddh@alibaba-inc.com> <601fe8e7-7111-4b8b-bafd-43ae8c0fa7f6.denghui.ddh@alibaba-inc.com> <2847C2A2-A680-489F-8AD1-B89229440034@oracle.com> <9ebd7f14-16ed-655a-0139-b08e219b0fde@oracle.com> <90dfa106-6fb2-4382-8087-78ae4ee291cc.denghui.ddh@alibaba-inc.com> <171E2CD6-4614-4CB0-A162-05FC6A6EE6CD@alibaba-inc.com> <33bcb20a-f92e-4e59-847f-50d877eb3247.denghui.ddh@alibaba-inc.com> <8D25EB0F-7456-4BE7-A1D0-CB733B150061@oracle.com> Message-ID: <68F785B4-730A-419D-B83F-647404B0A294@oracle.com> Yes, I can sponsor it. Erik > On 1 Apr 2020, at 16:43, Alan Bateman wrote: > > On 31/03/2020 17:22, Denghui Dong wrote: >> Hi Erik, >> >> IMO, one event type per pool is a better choice, because: >> 1. easy filtering and configuration as you said, and I don't think there will be too many buffer pool types in the future >> 2. some buffer pools may have extra fields, e.g. direct memory has max capacity limit. >> >> webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.05/ >> diff with webrev.04: http://cr.openjdk.java.net/~ddong/8238665/v4-v5.diff >> >> > This update looks good to me too. > > Erik, are you okay to sponsor this one? > From christoph.langer at sap.com Wed Apr 1 15:12:08 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 1 Apr 2020 15:12:08 +0000 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> Message-ID: Thanks for the review, Alan. I'll push it then. Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Mittwoch, 1. April 2020 16:46 > To: Langer, Christoph ; Mandy Chung > ; core-libs-dev at openjdk.java.net > Cc: build-dev > Subject: Re: RFR (S): 8241947: Minor comment fixes for system property > handling > > On 31/03/2020 19:57, Langer, Christoph wrote: > > Hi Mandy, > > > > this is a good suggestion. The listing of system properties at the props field > declaration seems somewhat redundant, given that it already exists more > exactly and with API normativity in the doc of System::getProperties(). > > > > So what do you think of this version: > http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ? > > > Mandy's suggestion to link to getProperties instead is good. This > version looks good to me. > > -Alan. From Roger.Riggs at oracle.com Wed Apr 1 16:03:58 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 1 Apr 2020 12:03:58 -0400 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> Message-ID: <3444d935-b584-b455-b484-ea244d0ed29e@oracle.com> Hi, Does dropping the "The following properties are guaranteed to be defined:" would seem to be a spec change. Just linking to the properties page makes no such guarantee. Roger On 4/1/20 10:45 AM, Alan Bateman wrote: > On 31/03/2020 19:57, Langer, Christoph wrote: >> Hi Mandy, >> >> this is a good suggestion. The listing of system properties at the >> props field declaration seems somewhat redundant, given that it >> already exists more exactly and with API normativity in the doc of >> System::getProperties(). >> >> So what do you think of this version: >> http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ ? >> > Mandy's suggestion to link to getProperties instead is good. This > version looks good to me. > > -Alan. From Alan.Bateman at oracle.com Wed Apr 1 16:06:04 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 17:06:04 +0100 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <3444d935-b584-b455-b484-ea244d0ed29e@oracle.com> References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> <3444d935-b584-b455-b484-ea244d0ed29e@oracle.com> Message-ID: <9b16550a-89b6-8844-b06b-b70b9125b4e8@oracle.com> On 01/04/2020 17:03, Roger Riggs wrote: > Hi, > > Does dropping the "The following properties are guaranteed to be > defined:" > would seem to be a spec change. It's a comment on a private field, there's no change to the getProperties spec. -Alan From mandy.chung at oracle.com Wed Apr 1 16:16:58 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 09:16:58 -0700 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> Message-ID: <754aabc3-dd68-8d25-63ee-a933b9b26c06@oracle.com> +1 Mandy On 3/31/20 11:57 AM, Langer, Christoph wrote: > > Hi Mandy, > > this is a good suggestion. The listing of system properties at the > props field declaration seems somewhat redundant, given that it > already exists more exactly and with API normativity in the doc of > System::getProperties(). > > So what do you think of this version: > http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/ > ? > > Thanks > > Christoph > > *From:* Mandy Chung > *Sent:* Dienstag, 31. M?rz 2020 19:34 > *To:* Langer, Christoph ; > core-libs-dev at openjdk.java.net > *Cc:* build-dev > *Subject:* Re: RFR (S): 8241947: Minor comment fixes for system > property handling > > On 3/31/20 7:56 AM, Langer, Christoph wrote: > > Hi, > > please review a small fix that updates two comments. > > The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property "vm.vendor" in VersionProps.java.template. However, there is no property "vm.vendor", it must rather be "java.vendor". I stumbled over that when looking at the change of JDK-4947890 (Minimize JNI upcalls in system-properties initialization). > > The second one is the code comment attached to "private static Properties props;" in java.lang.System. After JDK-8197927 (Allow the system property `java.vendor.version` to be undefined), "java.vendor.version" can be undefined, so this should be reflected in the comment. I also took the liberty to remove an unneeded import statement. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8241947 > > Webrev:http://cr.openjdk.java.net/~clanger/webrevs/8241947.0/ > > > I wonder if we still want to keep this block of comments listing a > subset of system properties.? Anyway the minor comment looks okay. > > Mandy > From Roger.Riggs at oracle.com Wed Apr 1 16:18:52 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 1 Apr 2020 12:18:52 -0400 Subject: RFR (S): 8241947: Minor comment fixes for system property handling In-Reply-To: <9b16550a-89b6-8844-b06b-b70b9125b4e8@oracle.com> References: <4a869bcd-c4ca-69b3-dc17-1dea871b1a4a@oracle.com> <591cfb84-418c-2b40-ba7f-15cebd6b1089@oracle.com> <3444d935-b584-b455-b484-ea244d0ed29e@oracle.com> <9b16550a-89b6-8844-b06b-b70b9125b4e8@oracle.com> Message-ID: <463d5160-c0ad-1d66-409b-36b8fa9ad6d9@oracle.com> My mistake, I mistook it for the spec table. On 4/1/20 12:06 PM, Alan Bateman wrote: > > > On 01/04/2020 17:03, Roger Riggs wrote: >> Hi, >> >> Does dropping the "The following properties are guaranteed to be >> defined:" >> would seem to be a spec change. > It's a comment on a private field, there's no change to the > getProperties spec. > > -Alan From mandy.chung at oracle.com Wed Apr 1 17:42:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 10:42:57 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 4/1/20 7:26 AM, Alan Bateman wrote: > Maybe I missed it going by, but why is the isHidden check in the field > offset methods on sun.misc.Unsafe rather than the internal Unsafe? The reflection and VarHandle implementation uses jdk.internal.misc.Unsafe to do field access (both read and write). For fields of a hidden declaring class, Field::get works on final and non-final fields.? Field::set will work on non-final fields and throw IAE on final fields.?? That's why no change to the internal Unsafe to support reflective field access. The check in the field offset methods in `sun.misc.Unsafe` intends to constrain the existing use of jdk.unsupported unsafe field offset methods to existing classes but not hidden classes (perhaps same to apply to inline classes) moving toward "trusted non-instance finals". Mandy From henry.jen at oracle.com Wed Apr 1 17:47:00 2020 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 1 Apr 2020 10:47:00 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <73D63A28-1FA2-45E8-BA34-17E2609C705D@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> <73D63A28-1FA2-45E8-BA34-17E2609C705D@tencent.com> Message-ID: <9E201F5C-1C0D-432A-8A1D-99F04C63690A@oracle.com> Yes, we need an official Reviewer to approve. I can help to push the change after that. Cheers, Henry > On Mar 31, 2020, at 9:55 PM, linzang(??) wrote: > > Thanks Henry, > > I agree to leave Solaris as it is, it seems to me there is no strong reason to remove it. > > So, Do I need more review before push this patch? > > And may I ask your help to push it if a go decision is made. > > Thanks. > > > BRs, > Lin > > ?On 2020/3/31, 12:30 PM, "Henry Jen" wrote: > > OK, I agree with David gettimeofday is an improvement than 1, so we can go ahead with the patch. Not sure if the caveat should be disclosed or not, I don?t think it?s important enough, just a known fact probably worth to leave a trace(perhaps a comment in code or the bug entry). As whether to change the ifdef to simply detect Solaris, I prefer just to leave it as is for two reasons: > > 1. It?s not broken, why change it? > 2. I checked the code, it?s just a simply macro defined by the make file. Realtime Linux extension would have that function and special custom build can still use that, even though that probably is not happening. > > Cheers, > Henry > > >> On Mar 30, 2020, at 7:39 PM, linzang(??) wrote: >> >> Hi David, Henry, Alan, >> Thanks a lot for your review. >> I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. >> Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. >> >> BRs, >> Lin >> >>> On 2020/3/31, 8:05 AM, "David Holmes" wrote: >>> >>> On 31/03/2020 4:08 am, Henry Jen wrote: >>>> Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use >>>> >>>> clock_gettime(CLOCK_MONOTONIC_RAW, ts); >>>> >>>> which I checked seems to be available on both Linux and Mac. Haven?t test it though. >>> >>> Not guaranteed to be available - either clock_gettime function or that >>> particular clock - at build time or runtime. We use a check in the build >>> system to determine build-time availability for hotspot, and then use >>> dl_lookup etc at runtime to determine if actually available. We should >>> be able to get rid of this one day but we checked fairly recently and >>> there were still some issues. >> >>> gettimeofday is a lot better than returning 1. Otherwise call into the >>> VM and use JVM_NanoTime. >>> >>> Cheers, >>> David >>> ----- >>> >>>> Cheers, >>>> Henry >>>> >>>>> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >>>>> >>>>> On 30/03/2020 03:41, linzang(??) wrote: >>>>>> Dear All, >>>>>> May I ask your help to reivew this tiny patch? Thanks. >>>>>> >>>>>> >>>>>> >>>>>> BRs, >>>>>> Lin >>>>>> >>>>>> From: "linzang(??)" >>>>>> Date: Thursday, March 26, 2020 at 3:13 PM >>>>>> To: "core-libs-dev at openjdk.java.net" >>>>>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >>>>>> >>>>>> Dear All, >>>>>> May I ask your help to review this tiny fix? >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >>>>>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >>>>>> Thanks! >>>>>> >>>>> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? >>>>> >>>>> -Alan >>>> >> >> >> > > > > From mandy.chung at oracle.com Wed Apr 1 18:43:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 11:43:14 -0700 Subject: Review Request 8238195: Lookup::defineClass should link the class to match the specification Message-ID: The spec of `Lookup::defineClass` specifies to throw linkage error including `VerifyError` and JDK-8238358 fixes the implementation to match the spec [1]. This patch updates the spec to make it clear as proposed in the CSR:https://bugs.openjdk.java.net/browse/JDK-8240338.? Also add a new test case to verify that `defineClass` does link a class. Webrev at: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ Thanks Mandy [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065456.html From mandy.chung at oracle.com Wed Apr 1 18:50:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 11:50:10 -0700 Subject: RFR 8015413 Reformat line in Class.privateGetPublicFields() to be more debugger-friendly In-Reply-To: References: Message-ID: <7dac4eae-a11f-f2a1-10a5-2424f867381b@oracle.com> IMHO the debugger should do a better job for us rather than we change the code to work for the debugger. Mandy On 3/31/20 12:02 AM, Vipin Mv1 wrote: > Hi All, > > Please find the below changes for the issue https://bugs.openjdk.java.net/browse/JDK-8015413 > > diff -r 53568400fec3 src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java Thu Mar 26 15:26:51 2020 +0000 > +++ b/src/java.base/share/classes/java/lang/Class.java Mon Mar 30 17:31:04 2020 +0530 > @@ -3163,7 +3163,8 @@ > ReflectionData rd = reflectionData(); > if (rd != null) { > res = rd.publicFields; > - if (res != null) return res; > + if (res != null) > + return res; > } > > // Use a linked hash set to ensure order is preserved and > > > > Thanks & Regards > Vipin MV > > From igor.ignatyev at oracle.com Wed Apr 1 19:13:09 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 1 Apr 2020 12:13:09 -0700 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: References: Message-ID: Hi Evgeny, (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out the names of created files, although this might potentially clutter the output, I don't think it'll be a problem given we already print out things like 'Gathering output for process ...' , 'Waiting for completion...' in LazyOutputBuffer. > The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). this doesn't include any of hotspot tiers, could you please also run hs-tier1--4? // you can use tierN jobs which include both jdk and hs parts. Thanks, -- Igor > On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin wrote: > > > Hi, > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 > > Webrev: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ > > > The bug had been created as a request to simplify investigation for compiler control tests failures. > I found the functionality pretty generic and useful and made ProcessTools dump output as well as some diagnostic information for every executed process into a separate file. > The diagnostic information contains cmdline, exit code, stdout and stderr. The output files are named like 'pid--output.log'. > > The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). > > Please review, > /Evgeny Nikitin. From Alan.Bateman at oracle.com Wed Apr 1 19:18:54 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 20:18:54 +0100 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <9E201F5C-1C0D-432A-8A1D-99F04C63690A@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> <73D63A28-1FA2-45E8-BA34-17E2609C705D@tencent.com> <9E201F5C-1C0D-432A-8A1D-99F04C63690A@oracle.com> Message-ID: <1f4e6945-b55a-1cd5-f479-3a3e40ee28de@oracle.com> On 01/04/2020 18:47, Henry Jen wrote: > Yes, we need an official Reviewer to approve. I can help to push the change after that. > I looked at the webrev01 but I don't think Lin has published the updated version yet. Happy to Review. -Alan From Alan.Bateman at oracle.com Wed Apr 1 19:53:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 20:53:36 +0100 Subject: Review Request 8238195: Lookup::defineClass should link the class to match the specification In-Reply-To: References: Message-ID: On 01/04/2020 19:43, Mandy Chung wrote: > The spec of `Lookup::defineClass` specifies to throw linkage error > including `VerifyError` and JDK-8238358 fixes the implementation to > match the spec [1]. > > This patch updates the spec to make it clear as proposed in the > CSR:https://bugs.openjdk.java.net/browse/JDK-8240338.? Also add a new > test case to verify that `defineClass` does link a class. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ The javadoc line and addition test look good. -Alan From paul.sandoz at oracle.com Wed Apr 1 22:46:55 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 Apr 2020 15:46:55 -0700 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests Message-ID: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> Hi, A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html This email expands the review of the API to the Java implementation and Java tests: http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) ? The Vector API provides - the public Vector class with vector operations common to all supported primitive types - public primitive specializations, such as IntVector, with common operations associated with the primitive type - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8201271 From ioi.lam at oracle.com Thu Apr 2 00:00:21 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 1 Apr 2020 17:00:21 -0700 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: References: Message-ID: <3bbe30fd-aae0-f55f-15f4-6a92ef918617@oracle.com> On 4/1/20 12:13 PM, Igor Ignatyev wrote: > Hi Evgeny, > > (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) > > overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out the names of created files, although this might potentially clutter the output, I don't think it'll be a problem given we already print out things like 'Gathering output for process ...' , 'Waiting for completion...' in LazyOutputBuffer. > FYI, We've been doing a similar thing with all the CDS tests -- all the logs from ProcessTools are saved, and we print out the name of stdout/stderr files in the .jtr files. It's been very valuable in diagnosing failures. Command line: [/home/iklam/jdk/bld/fre-fastdebug/images/jdk/bin/java -cp /jdk2/tmp/jtreg/work/classes/13/runtime/cds/appcds/HelloTest.d:/jdk2/fre/open/test/hotspot/jtreg/runtime/cds/appcds:/jdk2/tmp/jtreg/work/classes/13/test/lib:/jdk/tools/jtreg/5.0-b01/lib/javatest.jar:/jdk/tools/jtreg/5.0-b01/lib/jtreg.jar -XX:MaxRAM=8g -cp /jdk2/tmp/jtreg/work/classes/13/runtime/cds/appcds/HelloTest.d/hello.jar -Xshare:dump -Xlog:cds -XX:SharedArchiveFile=/jdk2/tmp/jtreg/work/scratch/2/appcds-23h24m40s432.jsa -XX:ExtraSharedClassListFile=/jdk2/tmp/jtreg/work/classes/13/runtime/cds/appcds/HelloTest.d/HelloTest-test.classlist ] [2020-04-01T06:24:40.530164Z] Gathering output for process 22666 [ELAPSED: 3068 ms] [logging stdout to HelloTest-0000-dump.stdout] [logging stderr to HelloTest-0000-dump.stderr] Thanks - Ioi >> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). > this doesn't include any of hotspot tiers, could you please also run hs-tier1--4? > // you can use tierN jobs which include both jdk and hs parts. > > Thanks, > -- Igor > >> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin wrote: >> >> >> Hi, >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >> >> Webrev: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >> >> >> The bug had been created as a request to simplify investigation for compiler control tests failures. >> I found the functionality pretty generic and useful and made ProcessTools dump output as well as some diagnostic information for every executed process into a separate file. >> The diagnostic information contains cmdline, exit code, stdout and stderr. The output files are named like 'pid--output.log'. >> >> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >> >> Please review, >> /Evgeny Nikitin. From david.holmes at oracle.com Thu Apr 2 00:07:31 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Apr 2020 17:07:31 -0700 (PDT) Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: References: Message-ID: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> Thanks for sharing this Igor! I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. Evgeny: Please run full tier testing at least to tier 6 and ideally beyond before pushing this. There are potential implications for temporary (and more permanent) disk usage as well as additional time needed to write files out to disk. (Hopefully these are generally small enough that this doesn't make a noticeable difference.) Thanks, David On 2/04/2020 5:13 am, Igor Ignatyev wrote: > Hi Evgeny, > > (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) > > overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out the names of created files, although this might potentially clutter the output, I don't think it'll be a problem given we already print out things like 'Gathering output for process ...' , 'Waiting for completion...' in LazyOutputBuffer. > >> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). > this doesn't include any of hotspot tiers, could you please also run hs-tier1--4? > // you can use tierN jobs which include both jdk and hs parts. > > Thanks, > -- Igor > >> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin wrote: >> >> >> Hi, >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >> >> Webrev: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >> >> >> The bug had been created as a request to simplify investigation for compiler control tests failures. >> I found the functionality pretty generic and useful and made ProcessTools dump output as well as some diagnostic information for every executed process into a separate file. >> The diagnostic information contains cmdline, exit code, stdout and stderr. The output files are named like 'pid--output.log'. >> >> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >> >> Please review, >> /Evgeny Nikitin. > From linzang at tencent.com Thu Apr 2 02:02:30 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 2 Apr 2020 02:02:30 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <1f4e6945-b55a-1cd5-f479-3a3e40ee28de@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <6A8A5F2C-9D7B-4BC6-8627-5D40FDC11608@oracle.com> <73D63A28-1FA2-45E8-BA34-17E2609C705D@tencent.com> <9E201F5C-1C0D-432A-8A1D-99F04C63690A@oracle.com> <1f4e6945-b55a-1cd5-f479-3a3e40ee28de@oracle.com> Message-ID: <2FD1BFD9-0679-4743-B89F-4B6B689BAD72@tencent.com> Hi Henry and Alan, Here is the updated webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev02/webrev/ Thanks a lot for your help! BRs, Lin ?On 2020/4/2, 3:20 AM, "Alan Bateman" wrote: On 01/04/2020 18:47, Henry Jen wrote: > Yes, we need an official Reviewer to approve. I can help to push the change after that. > I looked at the webrev01 but I don't think Lin has published the updated version yet. Happy to Review. -Alan From david.holmes at oracle.com Thu Apr 2 04:52:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 14:52:54 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Message-ID: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Hi Mandy, On 1/04/2020 1:01 pm, Mandy Chung wrote: > Thanks to the review feedbacks. > > Updated webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ I've had a good look through all the hotspot related changes. All looks good. A few minor comments: src/hotspot/share/ci/ciField.cpp // Trust VM hidden and unsafe anonymous classes. should say // Trust hidden and VM unsafe anonymous classes. // the private API (jdk.internal.misc.Unsafe) s/the/a/ or else change the () to commas or perhaps even better: // the private jdk.internal.misc.Unsafe API, --- src/hotspot/share/ci/ciInstanceKlass.cpp // VM weak hidden and unsafe anonymous classes should say // weak hidden and VM unsafe anonymous classes --- src/hotspot/share/classfile/classLoaderData.hpp ! // the CLDs lifecycle. For example, a non-strong hidden class or an ... ! // Used for weak hidden classes, unsafe anonymous classes and the There is an inconsistency in terminology, so far most code comments refer to "weak hidden" but now you are using "non-strong hidden". ! for an weak hidden s/an/a/ multiple locations --- src/hotspot/share/interpreter/linkResolver.cpp Can you fix one of my comments please (in two places) :) + // For private access check if there was a problem with nest host would read better as: + // For private access see if there was a problem with nest host --- Thanks, David ------ > Delta between webrev.03 and webrev.04: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ > > Summary of changes is: > 1. Update javac to retain the previous behavior when compiling to target > release <= 14 where lambda proxy class is not a nestmate > 2. Rename Class::isHiddenClass to Class::isHidden > 3. Address Joe's feedback on the CSR to document the behavior of the > relevant methods in java.lang.Class for hidden classes > 4. Add test case for unloadable class with nest host error > 5. Add test cases for hidden classes with different kinds of class or > interface > 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" > 7. Small changes in response to Remi, Coleen, Paul's review comments > 8. Fix copyright headers > 9. Fix @modules in tests > > Most of the changes above have also been reviewed as separate patches. > > Thanks > Mandy > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of Class::isHiddenClass), >> JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized >> state (see specdiff and javadoc below for reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Thu Apr 2 05:17:09 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 05:17:09 +0000 (UTC) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thanks for the edits to the comments.?? "weak hidden" were missed to be changed to "non-strong hidden".? Here is the patch fixing the comments. diff --git a/src/hotspot/share/ci/ciField.cpp b/src/hotspot/share/ci/ciField.cpp --- a/src/hotspot/share/ci/ciField.cpp +++ b/src/hotspot/share/ci/ciField.cpp @@ -223,8 +223,8 @@ ?????? holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || ?????? holder->is_in_package("java/lang")) ???? return true; -? // Trust VM hidden and unsafe anonymous classes. They are created via Lookup.defineClass or -? // the private API (jdk.internal.misc.Unsafe) and can't be serialized, so there is no hacking +? // Trust hidden and VM unsafe anonymous classes. They are created via Lookup.defineClass or +? // the private jdk.internal.misc.Unsafe API and can't be serialized, so there is no hacking ?? // of finals going on with them. ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) ???? return true; diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp b/src/hotspot/share/ci/ciInstanceKlass.cpp --- a/src/hotspot/share/ci/ciInstanceKlass.cpp +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp @@ -76,7 +76,7 @@ ?? oop holder = ik->klass_holder(); ?? if (ik->class_loader_data()->has_class_mirror_holder()) { ???? // Though ciInstanceKlass records class loader oop, it's not enough to keep -??? // VM weak hidden and unsafe anonymous classes alive (loader == NULL). Klass holder should +??? // non-strong hidden class and VM unsafe anonymous classes alive (loader == NULL). Klass holder should ???? // be used instead. It is enough to record a ciObject, since cached elements are never removed ???? // during ciObjectFactory lifetime. ciObjectFactory itself is created for ???? // every compilation and lives for the whole duration of the compilation. diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp --- a/src/hotspot/share/classfile/classLoaderData.hpp +++ b/src/hotspot/share/classfile/classLoaderData.hpp @@ -127,9 +127,10 @@ ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) ?? int _keep_alive;???????? // if this CLD is kept alive. -?????????????????????????? // Used for weak hidden classes, unsafe anonymous classes and the +?????????????????????????? // Used for non-strong hidden classes, unsafe anonymous classes and the ??????????????????????????? // boot class loader. _keep_alive does not need to be volatile or -?????????????????????????? // atomic since there is one unique CLD per weak hidden or unsafe anonymous class. +?????????????????????????? // atomic since there is one unique CLD per non-strong hidden class +?????????????????????????? // or unsafe anonymous class. ?? volatile int _claim; // non-zero if claimed, for example during GC traces. ??????????????????????? // To avoid applying oop closure more than once. @@ -242,15 +243,15 @@ ?? } ?? // Returns true if this class loader data is for the system class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_system_class_loader_data() const; ?? // Returns true if this class loader data is for the platform class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_platform_class_loader_data() const; ?? // Returns true if this class loader data is for the boot class loader. -? // (Note that the class loader data may be for an weak hidden unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? inline bool is_boot_class_loader_data() const; ?? bool is_builtin_class_loader_data() const; @@ -271,7 +272,7 @@ ???? return _unloading; ?? } -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in order to +? // Used to refcount a non-strong hidden class's or unsafe anonymous class's CLD in order to ?? // indicate their aliveness. ?? void inc_keep_alive(); ?? void dec_keep_alive(); diff --git a/src/hotspot/share/interpreter/linkResolver.cpp b/src/hotspot/share/interpreter/linkResolver.cpp --- a/src/hotspot/share/interpreter/linkResolver.cpp +++ b/src/hotspot/share/interpreter/linkResolver.cpp @@ -611,7 +611,7 @@ ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (sel_method->is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); @@ -951,7 +951,7 @@ ????????????? (same_module) ? "" : "; ", ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (fd.is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); Mandy On 4/1/20 9:52 PM, David Holmes wrote: > Hi Mandy, > > On 1/04/2020 1:01 pm, Mandy Chung wrote: >> Thanks to the review feedbacks. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >> > > I've had a good look through all the hotspot related changes. All > looks good. > > A few minor comments: > > src/hotspot/share/ci/ciField.cpp > > ?? // Trust VM hidden and unsafe anonymous classes. > > should say > > ?? // Trust hidden and VM unsafe anonymous classes. > > > ? // the private API (jdk.internal.misc.Unsafe) > > s/the/a/? or else change the () to commas or perhaps even better: > > ? // the private jdk.internal.misc.Unsafe API, > > --- > > src/hotspot/share/ci/ciInstanceKlass.cpp > > ? // VM weak hidden and unsafe anonymous classes > > should say > > ? // weak hidden and VM unsafe anonymous classes > > --- > > src/hotspot/share/classfile/classLoaderData.hpp > > !? // the CLDs lifecycle.? For example, a non-strong hidden class or an > ... > !? // Used for weak hidden classes, unsafe anonymous classes and the > > There is an inconsistency in terminology, so far most code comments > refer to "weak hidden" but now you are using "non-strong hidden". > > ! for an weak hidden > > s/an/a/?? multiple locations > > --- > > src/hotspot/share/interpreter/linkResolver.cpp > > Can you fix one of my comments please (in two places) :) > > +???? // For private access check if there was a problem with nest host > > would read better as: > > +???? // For private access see if there was a problem with nest host > > --- > > Thanks, > David > From david.holmes at oracle.com Thu Apr 2 06:21:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 16:21:10 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi Mandy, On 2/04/2020 3:17 pm, Mandy Chung wrote: > Hi David, > > Thanks for the edits to the comments.?? "weak hidden" were missed to be > changed to "non-strong hidden".? Here is the patch fixing the comments. There are 33 cases of "weak hidden" in the patch I reviewed and also some "hidden weak". Should they all be "non-strong hidden" now? In some cases it also appears in variables and associated logic ie.: src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp + _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), I'm not clear how far this terminology change needs to extend ?? Otherwise patch below seems fine. Thanks, David ----- > diff --git a/src/hotspot/share/ci/ciField.cpp > b/src/hotspot/share/ci/ciField.cpp > --- a/src/hotspot/share/ci/ciField.cpp > +++ b/src/hotspot/share/ci/ciField.cpp > @@ -223,8 +223,8 @@ > ?????? holder->is_in_package("jdk/internal/foreign") || > holder->is_in_package("jdk/incubator/foreign") || > ?????? holder->is_in_package("java/lang")) > ???? return true; > -? // Trust VM hidden and unsafe anonymous classes. They are created via > Lookup.defineClass or > -? // the private API (jdk.internal.misc.Unsafe) and can't be > serialized, so there is no hacking > +? // Trust hidden and VM unsafe anonymous classes. They are created via > Lookup.defineClass or > +? // the private jdk.internal.misc.Unsafe API and can't be serialized, > so there is no hacking > ?? // of finals going on with them. > ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) > ???? return true; > diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp > b/src/hotspot/share/ci/ciInstanceKlass.cpp > --- a/src/hotspot/share/ci/ciInstanceKlass.cpp > +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp > @@ -76,7 +76,7 @@ > ?? oop holder = ik->klass_holder(); > ?? if (ik->class_loader_data()->has_class_mirror_holder()) { > ???? // Though ciInstanceKlass records class loader oop, it's not > enough to keep > -??? // VM weak hidden and unsafe anonymous classes alive (loader == > NULL). Klass holder should > +??? // non-strong hidden class and VM unsafe anonymous classes alive > (loader == NULL). Klass holder should > ???? // be used instead. It is enough to record a ciObject, since > cached elements are never removed > ???? // during ciObjectFactory lifetime. ciObjectFactory itself is > created for > ???? // every compilation and lives for the whole duration of the > compilation. > diff --git a/src/hotspot/share/classfile/classLoaderData.hpp > b/src/hotspot/share/classfile/classLoaderData.hpp > --- a/src/hotspot/share/classfile/classLoaderData.hpp > +++ b/src/hotspot/share/classfile/classLoaderData.hpp > @@ -127,9 +127,10 @@ > ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) > > ?? int _keep_alive;???????? // if this CLD is kept alive. > -?????????????????????????? // Used for weak hidden classes, unsafe > anonymous classes and the > +?????????????????????????? // Used for non-strong hidden classes, > unsafe anonymous classes and the > ??????????????????????????? // boot class loader. _keep_alive does not > need to be volatile or > -?????????????????????????? // atomic since there is one unique CLD per > weak hidden or unsafe anonymous class. > +?????????????????????????? // atomic since there is one unique CLD per > non-strong hidden class > +?????????????????????????? // or unsafe anonymous class. > > ?? volatile int _claim; // non-zero if claimed, for example during GC > traces. > ??????????????????????? // To avoid applying oop closure more than once. > @@ -242,15 +243,15 @@ > ?? } > > ?? // Returns true if this class loader data is for the system class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_system_class_loader_data() const; > > ?? // Returns true if this class loader data is for the platform class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_platform_class_loader_data() const; > > ?? // Returns true if this class loader data is for the boot class loader. > -? // (Note that the class loader data may be for an weak hidden unsafe > anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? inline bool is_boot_class_loader_data() const; > > ?? bool is_builtin_class_loader_data() const; > @@ -271,7 +272,7 @@ > ???? return _unloading; > ?? } > > -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in > order to > +? // Used to refcount a non-strong hidden class's or unsafe anonymous > class's CLD in order to > ?? // indicate their aliveness. > ?? void inc_keep_alive(); > ?? void dec_keep_alive(); > > diff --git a/src/hotspot/share/interpreter/linkResolver.cpp > b/src/hotspot/share/interpreter/linkResolver.cpp > --- a/src/hotspot/share/interpreter/linkResolver.cpp > +++ b/src/hotspot/share/interpreter/linkResolver.cpp > @@ -611,7 +611,7 @@ > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (sel_method->is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > @@ -951,7 +951,7 @@ > ????????????? (same_module) ? "" : "; ", > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (fd.is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > > Mandy > > On 4/1/20 9:52 PM, David Holmes wrote: >> Hi Mandy, >> >> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>> Thanks to the review feedbacks. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>> >> >> I've had a good look through all the hotspot related changes. All >> looks good. >> >> A few minor comments: >> >> src/hotspot/share/ci/ciField.cpp >> >> ?? // Trust VM hidden and unsafe anonymous classes. >> >> should say >> >> ?? // Trust hidden and VM unsafe anonymous classes. >> >> >> ? // the private API (jdk.internal.misc.Unsafe) >> >> s/the/a/? or else change the () to commas or perhaps even better: >> >> ? // the private jdk.internal.misc.Unsafe API, >> >> --- >> >> src/hotspot/share/ci/ciInstanceKlass.cpp >> >> ? // VM weak hidden and unsafe anonymous classes >> >> should say >> >> ? // weak hidden and VM unsafe anonymous classes >> >> --- >> >> src/hotspot/share/classfile/classLoaderData.hpp >> >> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >> ... >> !? // Used for weak hidden classes, unsafe anonymous classes and the >> >> There is an inconsistency in terminology, so far most code comments >> refer to "weak hidden" but now you are using "non-strong hidden". >> >> ! for an weak hidden >> >> s/an/a/?? multiple locations >> >> --- >> >> src/hotspot/share/interpreter/linkResolver.cpp >> >> Can you fix one of my comments please (in two places) :) >> >> +???? // For private access check if there was a problem with nest host >> >> would read better as: >> >> +???? // For private access see if there was a problem with nest host >> >> --- >> >> Thanks, >> David >> > From david.holmes at oracle.com Thu Apr 2 06:53:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 16:53:33 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> Message-ID: <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> Hi Lin, On 31/03/2020 12:39 pm, linzang(??) wrote: > Hi David, Henry, Alan, > Thanks a lot for your review. > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. Leaving it as-is seems okay. Though the likelihood of anyone taking advantage of an existing gethrtime() function anywhere other than Solaris seems near zero. But if the Solaris port deprecation goes ahead the point will be moot as only the "linux" version will remain. This comment block needs fixing up: 37 /* 38 * * Add gethrtime() implementation for launch time debug on Linux. 39 * */ Also a nit but the new function can be called whatever you like as you are defining CounterGet, so calling it gethrtime() is a bit misleading - I suggest getTimeMicros(). Thanks, David > BRs, > Lin > > ?>On 2020/3/31, 8:05 AM, "David Holmes" wrote: >> >> On 31/03/2020 4:08 am, Henry Jen wrote: >> > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use >> > >> > clock_gettime(CLOCK_MONOTONIC_RAW, ts); >> > >> > which I checked seems to be available on both Linux and Mac. Haven?t test it though. >> >> Not guaranteed to be available - either clock_gettime function or that >> particular clock - at build time or runtime. We use a check in the build >> system to determine build-time availability for hotspot, and then use >> dl_lookup etc at runtime to determine if actually available. We should >> be able to get rid of this one day but we checked fairly recently and >> there were still some issues. > >> gettimeofday is a lot better than returning 1. Otherwise call into the >> VM and use JVM_NanoTime. >> >> Cheers, >> David >> ----- >> >> > Cheers, >> > Henry >> > >> >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >> >> >> >> On 30/03/2020 03:41, linzang(??) wrote: >> >>> Dear All, >> >>> May I ask your help to reivew this tiny patch? Thanks. >> >>> >> >>> >> >>> >> >>> BRs, >> >>> Lin >> >>> >> >>> From: "linzang(??)" >> >>> Date: Thursday, March 26, 2020 at 3:13 PM >> >>> To: "core-libs-dev at openjdk.java.net" >> >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >> >>> >> >>> Dear All, >> >>> May I ask your help to review this tiny fix? >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >> >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >> >>> Thanks! >> >>> >> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > >> > > >> -Alan > > > > > > From chris.hegarty at oracle.com Thu Apr 2 08:07:51 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 2 Apr 2020 01:07:51 -0700 (PDT) Subject: Review Request 8238195: Lookup::defineClass should link the class to match the specification In-Reply-To: References: Message-ID: > On 1 Apr 2020, at 19:43, Mandy Chung wrote: > .. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ LGTM. Trivially, you could update the copyright year range on the test. -Chris. From linzang at tencent.com Thu Apr 2 08:48:21 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 2 Apr 2020 08:48:21 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> Message-ID: <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> Hi David, Thanks to point it out, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241638/webrev03/ BRs, Lin ?On 2020/4/2, 2:54 PM, "David Holmes" wrote: Hi Lin, On 31/03/2020 12:39 pm, linzang(??) wrote: > Hi David, Henry, Alan, > Thanks a lot for your review. > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. Leaving it as-is seems okay. Though the likelihood of anyone taking advantage of an existing gethrtime() function anywhere other than Solaris seems near zero. But if the Solaris port deprecation goes ahead the point will be moot as only the "linux" version will remain. This comment block needs fixing up: 37 /* 38 * * Add gethrtime() implementation for launch time debug on Linux. 39 * */ Also a nit but the new function can be called whatever you like as you are defining CounterGet, so calling it gethrtime() is a bit misleading - I suggest getTimeMicros(). Thanks, David > BRs, > Lin > > >On 2020/3/31, 8:05 AM, "David Holmes" wrote: >> >> On 31/03/2020 4:08 am, Henry Jen wrote: >> > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use >> > >> > clock_gettime(CLOCK_MONOTONIC_RAW, ts); >> > >> > which I checked seems to be available on both Linux and Mac. Haven?t test it though. >> >> Not guaranteed to be available - either clock_gettime function or that >> particular clock - at build time or runtime. We use a check in the build >> system to determine build-time availability for hotspot, and then use >> dl_lookup etc at runtime to determine if actually available. We should >> be able to get rid of this one day but we checked fairly recently and >> there were still some issues. > >> gettimeofday is a lot better than returning 1. Otherwise call into the >> VM and use JVM_NanoTime. >> >> Cheers, >> David >> ----- >> >> > Cheers, >> > Henry >> > >> >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: >> >> >> >> On 30/03/2020 03:41, linzang(??) wrote: >> >>> Dear All, >> >>> May I ask your help to reivew this tiny patch? Thanks. >> >>> >> >>> >> >>> >> >>> BRs, >> >>> Lin >> >>> >> >>> From: "linzang(??)" >> >>> Date: Thursday, March 26, 2020 at 3:13 PM >> >>> To: "core-libs-dev at openjdk.java.net" >> >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set >> >>> >> >>> Dear All, >> >>> May I ask your help to review this tiny fix? >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 >> >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ >> >>> Thanks! >> >>> >> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > >> > > >> -Alan > > > > > > From david.holmes at oracle.com Thu Apr 2 10:05:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 20:05:48 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> Message-ID: On 2/04/2020 6:48 pm, linzang(??) wrote: > Hi David, > Thanks to point it out, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241638/webrev03/ As Alan pointed out this definition is not just for Linux. I would suggest this comment block: ! * Add CounterGet() implementation for launch time debug on Linux. ! * Use gettimeofday() here since the gethrtime() or clock_gettime() ! * may not be available for all Linux platforms. ! * The potential risk of using gettimeofday() is it can be affected ! * by settimeofday() or adjtime(). ! * Choose gettimeofday() here because it is more common on linux and ! * it is better than just return magic numbers for launch time debug. becomes simply: * Provide a CounterGet() implementation based on gettimeofday() which * is universally available, even though it may not be 'high resolution' * compared to platforms that provide gethrtime() (like Solaris). It is * also subject to time-of-day changes, but alternatives may not be * known to be available at either build time or run time. No need for updated webrev. Thanks, David > > BRs, > Lin > > ?On 2020/4/2, 2:54 PM, "David Holmes" wrote: > > Hi Lin, > > On 31/03/2020 12:39 pm, linzang(??) wrote: > > Hi David, Henry, Alan, > > Thanks a lot for your review. > > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. > > Leaving it as-is seems okay. Though the likelihood of anyone taking > advantage of an existing gethrtime() function anywhere other than > Solaris seems near zero. But if the Solaris port deprecation goes ahead > the point will be moot as only the "linux" version will remain. > > This comment block needs fixing up: > > 37 /* > 38 * * Add gethrtime() implementation for launch time debug on Linux. > 39 * */ > > Also a nit but the new function can be called whatever you like as you > are defining CounterGet, so calling it gethrtime() is a bit misleading - > I suggest getTimeMicros(). > > Thanks, > David > > > BRs, > > Lin > > > > >On 2020/3/31, 8:05 AM, "David Holmes" wrote: > >> > >> On 31/03/2020 4:08 am, Henry Jen wrote: > >> > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use > >> > > >> > clock_gettime(CLOCK_MONOTONIC_RAW, ts); > >> > > >> > which I checked seems to be available on both Linux and Mac. Haven?t test it though. > >> > >> Not guaranteed to be available - either clock_gettime function or that > >> particular clock - at build time or runtime. We use a check in the build > >> system to determine build-time availability for hotspot, and then use > >> dl_lookup etc at runtime to determine if actually available. We should > >> be able to get rid of this one day but we checked fairly recently and > >> there were still some issues. > > > >> gettimeofday is a lot better than returning 1. Otherwise call into the > >> VM and use JVM_NanoTime. > >> > >> Cheers, > >> David > >> ----- > >> > >> > Cheers, > >> > Henry > >> > > >> >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: > >> >> > >> >> On 30/03/2020 03:41, linzang(??) wrote: > >> >>> Dear All, > >> >>> May I ask your help to reivew this tiny patch? Thanks. > >> >>> > >> >>> > >> >>> > >> >>> BRs, > >> >>> Lin > >> >>> > >> >>> From: "linzang(??)" > >> >>> Date: Thursday, March 26, 2020 at 3:13 PM > >> >>> To: "core-libs-dev at openjdk.java.net" > >> >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set > >> >>> > >> >>> Dear All, > >> >>> May I ask your help to review this tiny fix? > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 > >> >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ > >> >>> Thanks! > >> >>> > >> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > > >> > > > >> -Alan > > > > > > > > > > > > > From linzang at tencent.com Thu Apr 2 10:21:41 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 2 Apr 2020 10:21:41 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> Message-ID: Dear David, Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ Thanks for your help! BRs, Lin ?On 2020/4/2, 6:06 PM, "David Holmes" wrote: On 2/04/2020 6:48 pm, linzang(??) wrote: > Hi David, > Thanks to point it out, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241638/webrev03/ As Alan pointed out this definition is not just for Linux. I would suggest this comment block: ! * Add CounterGet() implementation for launch time debug on Linux. ! * Use gettimeofday() here since the gethrtime() or clock_gettime() ! * may not be available for all Linux platforms. ! * The potential risk of using gettimeofday() is it can be affected ! * by settimeofday() or adjtime(). ! * Choose gettimeofday() here because it is more common on linux and ! * it is better than just return magic numbers for launch time debug. becomes simply: * Provide a CounterGet() implementation based on gettimeofday() which * is universally available, even though it may not be 'high resolution' * compared to platforms that provide gethrtime() (like Solaris). It is * also subject to time-of-day changes, but alternatives may not be * known to be available at either build time or run time. No need for updated webrev. Thanks, David > > BRs, > Lin > > On 2020/4/2, 2:54 PM, "David Holmes" wrote: > > Hi Lin, > > On 31/03/2020 12:39 pm, linzang(??) wrote: > > Hi David, Henry, Alan, > > Thanks a lot for your review. > > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. > > Leaving it as-is seems okay. Though the likelihood of anyone taking > advantage of an existing gethrtime() function anywhere other than > Solaris seems near zero. But if the Solaris port deprecation goes ahead > the point will be moot as only the "linux" version will remain. > > This comment block needs fixing up: > > 37 /* > 38 * * Add gethrtime() implementation for launch time debug on Linux. > 39 * */ > > Also a nit but the new function can be called whatever you like as you > are defining CounterGet, so calling it gethrtime() is a bit misleading - > I suggest getTimeMicros(). > > Thanks, > David > > > BRs, > > Lin > > > > >On 2020/3/31, 8:05 AM, "David Holmes" wrote: > >> > >> On 31/03/2020 4:08 am, Henry Jen wrote: > >> > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use > >> > > >> > clock_gettime(CLOCK_MONOTONIC_RAW, ts); > >> > > >> > which I checked seems to be available on both Linux and Mac. Haven?t test it though. > >> > >> Not guaranteed to be available - either clock_gettime function or that > >> particular clock - at build time or runtime. We use a check in the build > >> system to determine build-time availability for hotspot, and then use > >> dl_lookup etc at runtime to determine if actually available. We should > >> be able to get rid of this one day but we checked fairly recently and > >> there were still some issues. > > > >> gettimeofday is a lot better than returning 1. Otherwise call into the > >> VM and use JVM_NanoTime. > >> > >> Cheers, > >> David > >> ----- > >> > >> > Cheers, > >> > Henry > >> > > >> >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: > >> >> > >> >> On 30/03/2020 03:41, linzang(??) wrote: > >> >>> Dear All, > >> >>> May I ask your help to reivew this tiny patch? Thanks. > >> >>> > >> >>> > >> >>> > >> >>> BRs, > >> >>> Lin > >> >>> > >> >>> From: "linzang(??)" > >> >>> Date: Thursday, March 26, 2020 at 3:13 PM > >> >>> To: "core-libs-dev at openjdk.java.net" > >> >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set > >> >>> > >> >>> Dear All, > >> >>> May I ask your help to review this tiny fix? > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 > >> >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ > >> >>> Thanks! > >> >>> > >> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > > >> > > > >> -Alan > > > > > > > > > > > > > From linzang at tencent.com Thu Apr 2 10:26:33 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 2 Apr 2020 10:26:33 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> Message-ID: <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> >> No need for updated webrev. P.S. I mode the webrev update so it is easy for me to record the changes ?? Thanks! Lin ?On 2020/4/2, 6:21 PM, "linzang(??)" wrote: Dear David, Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ Thanks for your help! BRs, Lin On 2020/4/2, 6:06 PM, "David Holmes" wrote: On 2/04/2020 6:48 pm, linzang(??) wrote: > Hi David, > Thanks to point it out, I have uploaded a new patch at http://cr.openjdk.java.net/~lzang/8241638/webrev03/ As Alan pointed out this definition is not just for Linux. I would suggest this comment block: ! * Add CounterGet() implementation for launch time debug on Linux. ! * Use gettimeofday() here since the gethrtime() or clock_gettime() ! * may not be available for all Linux platforms. ! * The potential risk of using gettimeofday() is it can be affected ! * by settimeofday() or adjtime(). ! * Choose gettimeofday() here because it is more common on linux and ! * it is better than just return magic numbers for launch time debug. becomes simply: * Provide a CounterGet() implementation based on gettimeofday() which * is universally available, even though it may not be 'high resolution' * compared to platforms that provide gethrtime() (like Solaris). It is * also subject to time-of-day changes, but alternatives may not be * known to be available at either build time or run time. No need for updated webrev. Thanks, David > > BRs, > Lin > > On 2020/4/2, 2:54 PM, "David Holmes" wrote: > > Hi Lin, > > On 31/03/2020 12:39 pm, linzang(??) wrote: > > Hi David, Henry, Alan, > > Thanks a lot for your review. > > I have considered use clock_gettime() first, but I seached the code and found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which makes me think it may not be available under specific situation. So I choosed gettimeofday. > > Do you think the patch need to be refined to remove HAVE_GETHRTIME as Alan suggested? Thanks. > > Leaving it as-is seems okay. Though the likelihood of anyone taking > advantage of an existing gethrtime() function anywhere other than > Solaris seems near zero. But if the Solaris port deprecation goes ahead > the point will be moot as only the "linux" version will remain. > > This comment block needs fixing up: > > 37 /* > 38 * * Add gethrtime() implementation for launch time debug on Linux. > 39 * */ > > Also a nit but the new function can be called whatever you like as you > are defining CounterGet, so calling it gethrtime() is a bit misleading - > I suggest getTimeMicros(). > > Thanks, > David > > > BRs, > > Lin > > > > >On 2020/3/31, 8:05 AM, "David Holmes" wrote: > >> > >> On 31/03/2020 4:08 am, Henry Jen wrote: > >> > Based on my understanding to gethrtime(), the main benefit is not to be affected by settimeofday or adjtime. I think it is probably better to use > >> > > >> > clock_gettime(CLOCK_MONOTONIC_RAW, ts); > >> > > >> > which I checked seems to be available on both Linux and Mac. Haven?t test it though. > >> > >> Not guaranteed to be available - either clock_gettime function or that > >> particular clock - at build time or runtime. We use a check in the build > >> system to determine build-time availability for hotspot, and then use > >> dl_lookup etc at runtime to determine if actually available. We should > >> be able to get rid of this one day but we checked fairly recently and > >> there were still some issues. > > > >> gettimeofday is a lot better than returning 1. Otherwise call into the > >> VM and use JVM_NanoTime. > >> > >> Cheers, > >> David > >> ----- > >> > >> > Cheers, > >> > Henry > >> > > >> >> On Mar 30, 2020, at 1:37 AM, Alan Bateman wrote: > >> >> > >> >> On 30/03/2020 03:41, linzang(??) wrote: > >> >>> Dear All, > >> >>> May I ask your help to reivew this tiny patch? Thanks. > >> >>> > >> >>> > >> >>> > >> >>> BRs, > >> >>> Lin > >> >>> > >> >>> From: "linzang(??)" > >> >>> Date: Thursday, March 26, 2020 at 3:13 PM > >> >>> To: "core-libs-dev at openjdk.java.net" > >> >>> Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set > >> >>> > >> >>> Dear All, > >> >>> May I ask your help to review this tiny fix? > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241638 > >> >>> Webrev: http://cr.openjdk.java.net/~lzang/8241638/webrev01/ > >> >>> Thanks! > >> >>> > >> >> Using gettimeofday on non-Solaris platforms seems reasonable here. The comment in the patch suggests Linux but it's other Unix builds too. Also just a minor nit that the code in java.base uses 4-space indent, not 2. Looking at the patch makes me wondering if we should remove HAVE_GETHRTIME as it seems to be only used on Solaris >and the launcher is already using #ifdef __solaris__ in several places. Henry, do you have any comments on this? > > > >> > > > >> -Alan > > > > > > > > > > > > > From Alan.Bateman at oracle.com Thu Apr 2 13:17:47 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Apr 2020 14:17:47 +0100 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> Message-ID: On 02/04/2020 11:26, linzang(??) wrote: > : > Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ > Thanks for your help! > webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. -Alan. From christoph.langer at sap.com Thu Apr 2 15:01:28 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 Apr 2020 15:01:28 +0000 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin Message-ID: Hi, please review a small improvement for the jlink VersionPropsPlugin. The Plugin modifies the bytecode of java/lang/VersionProps.class to replace the initializion of certain vendor specific system properties with custom values. This modification currently adds two bytecodes per constant, a pop and another ldc. I overhauled it to simply replace the original ldc of the old value with another ldc, loading the custom value. I was playing a bit with the plugin and tried to familiarize with the code ? so that?s the outcome ?? I also added an @SuppressWarnings("unused") in VersionProps.java.template to quiesce an IDE warning. Bug: https://bugs.openjdk.java.net/browse/JDK-8242039 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242039.0/ Thanks Christoph From claes.redestad at oracle.com Thu Apr 2 15:23:47 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 2 Apr 2020 17:23:47 +0200 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: Message-ID: Hi Christoph, fun little micro-optimization. :-) My only nit is that I'd have preferred if you kept the indentation style, since the patch now shifts code around a bit (which makes it harder to review and see the history) /Claes On 2020-04-02 17:01, Langer, Christoph wrote: > Hi, > > please review a small improvement for the jlink VersionPropsPlugin. The Plugin modifies the bytecode of java/lang/VersionProps.class to replace the initializion of certain vendor specific system properties with custom values. This modification currently adds two bytecodes per constant, a pop and another ldc. I overhauled it to simply replace the original ldc of the old value with another ldc, loading the custom value. > > I was playing a bit with the plugin and tried to familiarize with the code ? so that?s the outcome ?? > > I also added an @SuppressWarnings("unused") in VersionProps.java.template to quiesce an IDE warning. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242039 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242039.0/ > > Thanks > Christoph > From christoph.langer at sap.com Thu Apr 2 18:21:42 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 Apr 2020 18:21:42 +0000 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: Message-ID: Hi Claes, > fun little micro-optimization. :-) Yep, I got a bit obsessed here. ?? But thanks for the review. > My only nit is that I'd have preferred if you kept the indentation > style, since the patch now shifts code around a bit (which makes it > harder to review and see the history) OK, I created an edition which doesn't change the formatting so that the added code becomes more obvious: http://cr.openjdk.java.net/~clanger/webrevs/8242039.1/ Does it look better? Cheers Christoph > > /Claes > > > On 2020-04-02 17:01, Langer, Christoph wrote: > > Hi, > > > > please review a small improvement for the jlink VersionPropsPlugin. The > Plugin modifies the bytecode of java/lang/VersionProps.class to replace the > initializion of certain vendor specific system properties with custom values. > This modification currently adds two bytecodes per constant, a pop and > another ldc. I overhauled it to simply replace the original ldc of the old value > with another ldc, loading the custom value. > > > > I was playing a bit with the plugin and tried to familiarize with the code ? so > that?s the outcome ?? > > > > I also added an @SuppressWarnings("unused") in > VersionProps.java.template to quiesce an IDE warning. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242039 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242039.0/ > > > > Thanks > > Christoph > > From mandy.chung at oracle.com Thu Apr 2 18:56:47 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 11:56:47 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thank you for checking thoroughly.?? I now grep on src/hotspot and clean all of them. Updated delta webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ On 4/1/20 11:21 PM, David Holmes wrote: > Hi Mandy, > > On 2/04/2020 3:17 pm, Mandy Chung wrote: >> Hi David, >> >> Thanks for the edits to the comments.?? "weak hidden" were missed to >> be changed to "non-strong hidden".? Here is the patch fixing the >> comments. > > There are 33 cases of "weak hidden" in the patch I reviewed and also > some "hidden weak". Should they all be "non-strong hidden" now? yes, supposed to.?? All should be fixed in webrev.04-delta. > In some cases it also appears in variables and associated logic ie.: > > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp > > +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), > Are you reading webrev.03???? This has been fixed in webrev.04. I found Klass::is_hidden_weak that should have been renamed too. > I'm not clear how far this terminology change needs to extend ?? > I hope consistently used in the source. > Otherwise patch below seems fine. > Revised the patch. Thanks Mandy > Thanks, > David > ----- > > >> diff --git a/src/hotspot/share/ci/ciField.cpp >> b/src/hotspot/share/ci/ciField.cpp >> --- a/src/hotspot/share/ci/ciField.cpp >> +++ b/src/hotspot/share/ci/ciField.cpp >> @@ -223,8 +223,8 @@ >> ??????? holder->is_in_package("jdk/internal/foreign") || >> holder->is_in_package("jdk/incubator/foreign") || >> ??????? holder->is_in_package("java/lang")) >> ????? return true; >> -? // Trust VM hidden and unsafe anonymous classes. They are created >> via Lookup.defineClass or >> -? // the private API (jdk.internal.misc.Unsafe) and can't be >> serialized, so there is no hacking >> +? // Trust hidden and VM unsafe anonymous classes. They are created >> via Lookup.defineClass or >> +? // the private jdk.internal.misc.Unsafe API and can't be >> serialized, so there is no hacking >> ??? // of finals going on with them. >> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >> ????? return true; >> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >> b/src/hotspot/share/ci/ciInstanceKlass.cpp >> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >> @@ -76,7 +76,7 @@ >> ??? oop holder = ik->klass_holder(); >> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >> ????? // Though ciInstanceKlass records class loader oop, it's not >> enough to keep >> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >> NULL). Klass holder should >> +??? // non-strong hidden class and VM unsafe anonymous classes alive >> (loader == NULL). Klass holder should >> ????? // be used instead. It is enough to record a ciObject, since >> cached elements are never removed >> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >> created for >> ????? // every compilation and lives for the whole duration of the >> compilation. >> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >> b/src/hotspot/share/classfile/classLoaderData.hpp >> --- a/src/hotspot/share/classfile/classLoaderData.hpp >> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >> @@ -127,9 +127,10 @@ >> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >> support) >> >> ??? int _keep_alive;???????? // if this CLD is kept alive. >> -?????????????????????????? // Used for weak hidden classes, unsafe >> anonymous classes and the >> +?????????????????????????? // Used for non-strong hidden classes, >> unsafe anonymous classes and the >> ???????????????????????????? // boot class loader. _keep_alive does >> not need to be volatile or >> -?????????????????????????? // atomic since there is one unique CLD >> per weak hidden or unsafe anonymous class. >> +?????????????????????????? // atomic since there is one unique CLD >> per non-strong hidden class >> +?????????????????????????? // or unsafe anonymous class. >> >> ??? volatile int _claim; // non-zero if claimed, for example during >> GC traces. >> ???????????????????????? // To avoid applying oop closure more than >> once. >> @@ -242,15 +243,15 @@ >> ??? } >> >> ??? // Returns true if this class loader data is for the system class >> loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_system_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the platform >> class loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_platform_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the boot class >> loader. >> -? // (Note that the class loader data may be for an weak hidden >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? inline bool is_boot_class_loader_data() const; >> >> ??? bool is_builtin_class_loader_data() const; >> @@ -271,7 +272,7 @@ >> ????? return _unloading; >> ??? } >> >> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >> in order to >> +? // Used to refcount a non-strong hidden class's or unsafe >> anonymous class's CLD in order to >> ??? // indicate their aliveness. >> ??? void inc_keep_alive(); >> ??? void dec_keep_alive(); >> >> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >> b/src/hotspot/share/interpreter/linkResolver.cpp >> --- a/src/hotspot/share/interpreter/linkResolver.cpp >> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >> @@ -611,7 +611,7 @@ >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (sel_method->is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> @@ -951,7 +951,7 @@ >> ?????????????? (same_module) ? "" : "; ", >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (fd.is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> >> Mandy >> >> On 4/1/20 9:52 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>> Thanks to the review feedbacks. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>> >>> >>> I've had a good look through all the hotspot related changes. All >>> looks good. >>> >>> A few minor comments: >>> >>> src/hotspot/share/ci/ciField.cpp >>> >>> ?? // Trust VM hidden and unsafe anonymous classes. >>> >>> should say >>> >>> ?? // Trust hidden and VM unsafe anonymous classes. >>> >>> >>> ? // the private API (jdk.internal.misc.Unsafe) >>> >>> s/the/a/? or else change the () to commas or perhaps even better: >>> >>> ? // the private jdk.internal.misc.Unsafe API, >>> >>> --- >>> >>> src/hotspot/share/ci/ciInstanceKlass.cpp >>> >>> ? // VM weak hidden and unsafe anonymous classes >>> >>> should say >>> >>> ? // weak hidden and VM unsafe anonymous classes >>> >>> --- >>> >>> src/hotspot/share/classfile/classLoaderData.hpp >>> >>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>> ... >>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>> >>> There is an inconsistency in terminology, so far most code comments >>> refer to "weak hidden" but now you are using "non-strong hidden". >>> >>> ! for an weak hidden >>> >>> s/an/a/?? multiple locations >>> >>> --- >>> >>> src/hotspot/share/interpreter/linkResolver.cpp >>> >>> Can you fix one of my comments please (in two places) :) >>> >>> +???? // For private access check if there was a problem with nest host >>> >>> would read better as: >>> >>> +???? // For private access see if there was a problem with nest host >>> >>> --- >>> >>> Thanks, >>> David >>> >> From alexey.semenyuk at oracle.com Thu Apr 2 19:51:26 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 2 Apr 2020 15:51:26 -0400 Subject: RFR: JDK-8241713: Linux desktop shortcuts with spaces make postinst/prerm fail In-Reply-To: References: Message-ID: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com> Please review fix [2] for jpackage bug [1]. Replace space characters in names of files registered by jpackage with X Desktop in postinstall step of rpm and deb installers. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8241713 [2]?http://cr.openjdk.java.net/~asemenyuk/8241713/webrev.00 From lois.foltan at oracle.com Thu Apr 2 20:28:07 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 2 Apr 2020 16:28:07 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <333b05fb-65c6-e8ef-a804-b624c2da56c5@oracle.com> On 4/2/2020 2:56 PM, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and > clean all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > Patch looks good Mandy. Lois > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes >>> alive (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's >>> CLD in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class >>>> or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest >>>> host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From claes.redestad at oracle.com Thu Apr 2 21:05:27 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 2 Apr 2020 23:05:27 +0200 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: Message-ID: <3d94877d-9104-73a2-1228-829ef4a64fa3@oracle.com> On 2020-04-02 20:21, Langer, Christoph wrote: > OK, I created an edition which doesn't change the formatting so that the added code becomes more obvious: > http://cr.openjdk.java.net/~clanger/webrevs/8242039.1/ > > Does it look better? I think so, yes. /Claes From andy.herrick at oracle.com Thu Apr 2 21:04:07 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 2 Apr 2020 17:04:07 -0400 Subject: RFR: JDK-8241713: Linux desktop shortcuts with spaces make postinst/prerm fail In-Reply-To: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com> References: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com> Message-ID: <604b1245-399e-cb74-6247-c98d249a58e9@oracle.com> looks good. /Andy On 4/2/2020 3:51 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Replace space characters in names of files registered by jpackage with > X Desktop in postinstall step of rpm and deb installers. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8241713 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8241713/webrev.00 > From mark.reinhold at oracle.com Thu Apr 2 21:12:54 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Apr 2020 14:12:54 -0700 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: Message-ID: <20200402141254.742895118@eggemoggin.niobe.net> 2020/4/2 8:01:28 -0700, christoph.langer at sap.com: > please review a small improvement for the jlink > VersionPropsPlugin. The Plugin modifies the bytecode of > java/lang/VersionProps.class to replace the initializion of certain > vendor specific system properties with custom values. This > modification currently adds two bytecodes per constant, a pop and > another ldc. I overhauled it to simply replace the original ldc of the > old value with another ldc, loading the custom value. I thought about doing this when I originally wrote that plugin, but it?s so awkward to achieve with ASM -- as demonstrated by your patch -- that I concluded it wasn?t worth it. Who will notice an extra pop in a basic block that?s only ever executed once? Is the complexity of this new code worth the benefit? - Mark From mandy.chung at oracle.com Thu Apr 2 21:25:04 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 14:25:04 -0700 Subject: Review Request 8238195: Lookup::defineClass should link the class to match the specification In-Reply-To: References: Message-ID: On 4/2/20 1:07 AM, Chris Hegarty wrote: >> On 1 Apr 2020, at 19:43, Mandy Chung wrote: >> .. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/ > LGTM. Trivially, you could update the copyright year range on the test. > Updated. thanks Mandy From alexander.matveev at oracle.com Thu Apr 2 21:35:03 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Thu, 2 Apr 2020 14:35:03 -0700 Subject: RFR: JDK-8241713: Linux desktop shortcuts with spaces make postinst/prerm fail In-Reply-To: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com> References: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com> Message-ID: <47bc7f29-0d01-0fed-0cc5-de851d5c020e@oracle.com> Hi Alexey, Looks good. Thanks, Alexander On 4/2/20 12:51 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Replace space characters in names of files registered by jpackage with > X Desktop in postinstall step of rpm and deb installers. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8241713 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8241713/webrev.00 > From david.holmes at oracle.com Fri Apr 3 01:36:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Apr 2020 11:36:03 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <10e51a8a-6d69-db08-d4f9-f578ec591ee2@oracle.com> Hi Mandy, Update seems fine. Thanks, David On 3/04/2020 4:56 am, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and clean > all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes alive >>> (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >>> in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From peter.levart at gmail.com Fri Apr 3 09:11:04 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 11:11:04 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: Hi Mandy, Good work. I'm trying to find out which language use-case is covered by the InnerClassLambdaMetafactory needing to inject method handle into the generated proxy class to be invoked instead of proxy class directly invoking the method: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If I check what implClass and implInfo get resolved to in AbstractValidatingLambdaMetafactory, there are several cases: ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ??????????????? // reference kind reported by implInfo may not match implMethodType's first param ??????????????? // Example: implMethodType is (Cloneable)String, implInfo is for Object.toString ??????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? this.implIsInstanceMethod = true; ??????????????? break; ??????????? case REF_invokeSpecial: ??????????????? // JDK-8172817: should use referenced class here, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implIsInstanceMethod = true; ??????????????? // Classes compiled prior to dynamic nestmate support invokes a private instance ??????????????? // method with REF_invokeSpecial. ??????????????? // ??????????????? // invokespecial should only be used to invoke private nestmate constructors. ??????????????? // The lambda proxy class will be defined as a nestmate of targetClass. ??????????????? // If the method to be invoked is an instance method of targetClass, then ??????????????? // convert to use invokevirtual or invokeinterface. ??????????????? if (targetClass == implClass && !implInfo.getName().equals("")) { ??????????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? } else { ??????????????????? this.implKind = REF_invokeSpecial; ??????????????? } ??????????????? break; ??????????? case REF_invokeStatic: ??????????? case REF_newInvokeSpecial: ??????????????? // JDK-8172817: should use referenced class here for invokestatic, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implKind = implInfo.getReferenceKind(); ??????????????? this.implIsInstanceMethod = false; ??????????????? break; ??????????? default: ??????????????? throw new LambdaConversionException(String.format("Unsupported MethodHandle kind: %s", implInfo)); ??????? } For majority of cases (REF_invokeSpecial, REF_invokeStatic, REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); Only REF_invokeVirtual and REF_invokeInterface are possible kandidates, right? So when does the implMethod type of parameter 0 differ from the declaring class of the MethodHandleInfo cracked from that same implMethod and in addition those two types leave in different packages? Regards, Peter On 3/27/20 12:57 AM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From christoph.dreis at freenet.de Fri Apr 3 10:19:25 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 03 Apr 2020 12:19:25 +0200 Subject: Use Method.getParameterCount() where possible Message-ID: <9865F20E-0B64-4C78-9819-14579D7C0FE7@freenet.de> Hi, I noticed that the JDK itself still uses Method.getParameterTypes().length in a couple of places. This could be replaced with Method.getParameterCount() to avoid unnecessary cloning overhead. While this is often optimized away, I guess it's still good to not rely on that. Additionally, it's a little more concise to read. If you think this is worthwhile, I would need someone to sponsor that tiny change. P.S.: There is another occurrence in ForkJoinTask where I wasn't sure if I should change that, because it's usually changed under the JSR166 umbrella afaik. Cheers, Christoph ==== PATCH ==== diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java @@ -276,13 +276,13 @@ switch (m.getName()) { case "toString": return (m.getReturnType() == String.class - && m.getParameterTypes().length == 0); + && m.getParameterCount() == 0); case "hashCode": return (m.getReturnType() == int.class - && m.getParameterTypes().length == 0); + && m.getParameterCount() == 0); case "equals": return (m.getReturnType() == boolean.class - && m.getParameterTypes().length == 1 + && m.getParameterCount() == 1 && m.getParameterTypes()[0] == Object.class); } return false; diff --git a/src/java.base/share/classes/java/lang/reflect/Executable.java b/src/java.base/share/classes/java/lang/reflect/Executable.java --- a/src/java.base/share/classes/java/lang/reflect/Executable.java +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java @@ -378,7 +378,7 @@ private void verifyParameters(final Parameter[] parameters) { final int mask = Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; - if (getParameterTypes().length != parameters.length) + if (getParameterCount() != parameters.length) throw new MalformedParametersException("Wrong number of parameters in MethodParameters attribute"); for (Parameter parameter : parameters) { diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java @@ -121,7 +121,7 @@ if (Modifier.isPublic(method.getModifiers()) && Modifier.isAbstract(method.getModifiers()) && !method.isSynthetic()) { - if (method.getParameterTypes().length != 0) { + if (method.getParameterCount() != 0) { throw new IllegalArgumentException(method + " has params"); } String name = method.getName(); From peter.levart at gmail.com Fri Apr 3 11:40:54 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 13:40:54 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Ok, I think I found one such use-case. In the following example: package test; public class LambdaTest { ??? protected void m() { ??? } } package test.sub; public class LambdaTestSub extends test.LambdaTest { ??? public void test() { ??????? Runnable r = this::m; ??????? r.run(); ??? } } ...when compiled with JDK 14 javac. In this case the implClass is test.sub.LambdaTestSub while implInfo is "invokeVirtual test.LambdaTest.m:()void" and the method is not public. Anyway, the name of the proxy class is derived from the targetClass (and therefore shares the same package with targetClass) which is caller's lookup class. Is targetClass always the same as implClass in the invokeVirtual/invokeInterface case? I also noticed that JDK 15 patched javac transforms method reference in above code into a lambda method. But looking at the javac changes in the patch, I don't quite see where this distinction between JDK 14 and patched JDK 15 javac comes from. From the changes to method com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: ??????????? final boolean needsConversionToLambda() { ??????????????? return interfaceParameterIsIntersectionOrUnionType() || ??????????????????????? isSuper || ??????????????????????? needsVarArgsConversion() || ??????????????????????? isArrayOp() || #??????????????????????? isPrivateInOtherClass() || isProtectedInSuperClassOfEnclosingClassInOtherPackage() || ??????????????????????? !receiverAccessible() || ??????????????????????? (tree.getMode() == ReferenceMode.NEW && ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && ????????????????????????? (tree.sym.owner.isLocal() || tree.sym.owner.isInner())); ??????????? } ...I would draw the conclusion that conversion to lambda is performed in less cases not in more. Hm. Regards, Peter On 4/3/20 11:11 AM, Peter Levart wrote: > Hi Mandy, > > Good work. > > I'm trying to find out which language use-case is covered by the > InnerClassLambdaMetafactory needing to inject method handle into the > generated proxy class to be invoked instead of proxy class directly > invoking the method: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If I check what implClass and implInfo get resolved to in > AbstractValidatingLambdaMetafactory, there are several cases: > > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > ??????????????? // reference kind reported by implInfo may not match > implMethodType's first param > ??????????????? // Example: implMethodType is (Cloneable)String, > implInfo is for Object.toString > ??????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? this.implIsInstanceMethod = true; > ??????????????? break; > ??????????? case REF_invokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here, but > we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implIsInstanceMethod = true; > > ??????????????? // Classes compiled prior to dynamic nestmate support > invokes a private instance > ??????????????? // method with REF_invokeSpecial. > ??????????????? // > ??????????????? // invokespecial should only be used to invoke private > nestmate constructors. > ??????????????? // The lambda proxy class will be defined as a > nestmate of targetClass. > ??????????????? // If the method to be invoked is an instance method > of targetClass, then > ??????????????? // convert to use invokevirtual or invokeinterface. > ??????????????? if (targetClass == implClass && > !implInfo.getName().equals("")) { > ??????????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? } else { > ??????????????????? this.implKind = REF_invokeSpecial; > ??????????????? } > ??????????????? break; > ??????????? case REF_invokeStatic: > ??????????? case REF_newInvokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here for > invokestatic, but we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implKind = implInfo.getReferenceKind(); > ??????????????? this.implIsInstanceMethod = false; > ??????????????? break; > ??????????? default: > ??????????????? throw new > LambdaConversionException(String.format("Unsupported MethodHandle > kind: %s", implInfo)); > ??????? } > > > For majority of cases (REF_invokeSpecial, REF_invokeStatic, > REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); > > Only REF_invokeVirtual and REF_invokeInterface are possible > kandidates, right? > > So when does the implMethod type of parameter 0 differ from the > declaring class of the MethodHandleInfo cracked from that same > implMethod and in addition those two types leave in different packages? > > Regards, Peter > > > On 3/27/20 12:57 AM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From andy.herrick at oracle.com Fri Apr 3 13:24:56 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 3 Apr 2020 09:24:56 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> Message-ID: <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> please review this revised webrev [4] to issue [2] The previous version generated a signed app that could be notarized, but then couldn't run because signing the whole app resigned the executable with reduced entitlements. This revision adds back in the entitlements when signing the whole app, as well as fixing the unit test that was failing the spctl call on Catalina due to signed app not being notarized. /Andy On 3/30/2020 1:19 PM, Andy Herrick wrote: > revised with minor fixes as per below - webrev at [3] > > [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ > > /Andy > > On 3/28/2020 9:43 AM, Andy Herrick wrote: >> >> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>> Hi Andy, >>> >>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>> >>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>> align with rest of code. >> I will fix this. >>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>> >>> Line 70 - Capital F. >> and this >>> >>> Since we added "--timestamp" and? "--options runtime" to codesign, >>> will it work with older Xcode and macOS we planning to support? >> not sure - may need some discussion of what we support and possible >> conditional code here. >>> >>> Do we need any adjustments to signing tests we have? >> >> The existing tests pass, but this is not unexpected (and really means >> nothing) since the signing tests are all skipped unless specific test >> certs are installed on target machine. >> >> We need further discussion how one is expected to provision a machine >> to run these tests. >> >> /Andy >> >>> >>> Otherwise looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>> Please review the fix to issue [1] at [2]. >>>> >>>> This change enables notarization on Mac for dmg images and >>>> app-image zip files. >>>> >>>> /Andy >>>> >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>> >>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>> >>> From christoph.langer at sap.com Fri Apr 3 13:36:53 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 3 Apr 2020 13:36:53 +0000 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: <20200402141254.742895118@eggemoggin.niobe.net> References: <20200402141254.742895118@eggemoggin.niobe.net> Message-ID: Hi Mark, > -----Original Message----- > From: mark.reinhold at oracle.com > Sent: Donnerstag, 2. April 2020 23:13 > To: Langer, Christoph > Cc: jigsaw-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin > > 2020/4/2 8:01:28 -0700, christoph.langer at sap.com: > > please review a small improvement for the jlink > > VersionPropsPlugin. The Plugin modifies the bytecode of > > java/lang/VersionProps.class to replace the initializion of certain > > vendor specific system properties with custom values. This > > modification currently adds two bytecodes per constant, a pop and > > another ldc. I overhauled it to simply replace the original ldc of the > > old value with another ldc, loading the custom value. > > I thought about doing this when I originally wrote that plugin, but it?s > so awkward to achieve with ASM -- as demonstrated by your patch -- that > I concluded it wasn?t worth it. Who will notice an extra pop in a basic > block that?s only ever executed once? Is the complexity of this new > code worth the benefit? Well, first I started playing with this and got a bit obsessed to find optimizations in that area. (I learned quite a bit about java asm.) It would be of higher (micro-)benefit for common VM startup if the fields to be modified could be final but that's even more awkward to do and requires intricate knowledge and assumptions about how VersionProps.java is structured. So I decided against messing with that. Eventually I came up with this result and then I also asked myself the question whether the new complexity was worth the benefit. I answered myself with a yes (though definitely not a clear one ??), and that's why I proposed the change. After all, the new complexity isn't huge... So, would that be your terminal veto or could you imagine accepting the change? Best regards Christoph From christoph.langer at sap.com Fri Apr 3 13:37:06 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 3 Apr 2020 13:37:06 +0000 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: <3d94877d-9104-73a2-1228-829ef4a64fa3@oracle.com> References: <3d94877d-9104-73a2-1228-829ef4a64fa3@oracle.com> Message-ID: Thanks, Claes. > -----Original Message----- > From: Claes Redestad > Sent: Donnerstag, 2. April 2020 23:05 > To: Langer, Christoph ; jigsaw- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8242039: Improve jlink VersionPropsPlugin > > > > On 2020-04-02 20:21, Langer, Christoph wrote: > > OK, I created an edition which doesn't change the formatting so that the > added code becomes more obvious: > > http://cr.openjdk.java.net/~clanger/webrevs/8242039.1/ > > > > Does it look better? > > I think so, yes. > > /Claes From andy.herrick at oracle.com Fri Apr 3 14:20:21 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 3 Apr 2020 10:20:21 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> Message-ID: sorry missing webrev pointer [4] [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 /Andy On 4/3/2020 9:24 AM, Andy Herrick wrote: > please review this revised webrev [4] to issue [2] > > The previous version generated a signed app that could be notarized, > but then couldn't run because signing the whole app resigned the > executable with reduced entitlements. > > This revision adds back in the entitlements when signing the whole > app, as well as fixing the unit test that was failing the spctl call > on Catalina due to signed app not being notarized. > > > /Andy > > On 3/30/2020 1:19 PM, Andy Herrick wrote: >> revised with minor fixes as per below - webrev at [3] >> >> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >> >> /Andy >> >> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>> >>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>> Hi Andy, >>>> >>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>> >>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>> align with rest of code. >>> I will fix this. >>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>> >>>> Line 70 - Capital F. >>> and this >>>> >>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>> will it work with older Xcode and macOS we planning to support? >>> not sure - may need some discussion of what we support and possible >>> conditional code here. >>>> >>>> Do we need any adjustments to signing tests we have? >>> >>> The existing tests pass, but this is not unexpected (and really >>> means nothing) since the signing tests are all skipped unless >>> specific test certs are installed on target machine. >>> >>> We need further discussion how one is expected to provision a >>> machine to run these tests. >>> >>> /Andy >>> >>>> >>>> Otherwise looks fine. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>> Please review the fix to issue [1] at [2]. >>>>> >>>>> This change enables notarization on Mac for dmg images and >>>>> app-image zip files. >>>>> >>>>> /Andy >>>>> >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>> >>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>> >>>> From james at deepsymmetry.org Fri Apr 3 14:40:07 2020 From: james at deepsymmetry.org (James Elliott) Date: Fri, 3 Apr 2020 09:40:07 -0500 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg (Andy Herrick) In-Reply-To: References: Message-ID: This sounds promising! I just wanted to check if there is a mechanism to specify a custom set of entitlements needed by the application when running jpackage, in case it needs more than the normal set that Java itself does. Or does Java already ask for every possible entitlement in its original notarization? Thanks, -James > Date: Fri, 3 Apr 2020 10:20:21 -0400 > From: Andy Herrick > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR: JDK-8237490: [macos] Add support notarizing jpackage > app-image and dmg > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > sorry missing webrev pointer [4] > > [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 > > /Andy > > On 4/3/2020 9:24 AM, Andy Herrick wrote: >> please review this revised webrev [4] to issue [2] >> >> The previous version generated a signed app that could be notarized, >> but then couldn't run because signing the whole app resigned the >> executable with reduced entitlements. >> >> This revision adds back in the entitlements when signing the whole >> app, as well as fixing the unit test that was failing the spctl call >> on Catalina due to signed app not being notarized. >> >> >> /Andy >> >> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>> revised with minor fixes as per below - webrev at [3] >>> >>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>> >>> /Andy >>> >>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>> >>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>> Hi Andy, >>>>> >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>> >>>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>>> align with rest of code. >>>> I will fix this. >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>> >>>>> Line 70 - Capital F. >>>> and this >>>>> >>>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>>> will it work with older Xcode and macOS we planning to support? >>>> not sure - may need some discussion of what we support and possible >>>> conditional code here. >>>>> >>>>> Do we need any adjustments to signing tests we have? >>>> >>>> The existing tests pass, but this is not unexpected (and really >>>> means nothing) since the signing tests are all skipped unless >>>> specific test certs are installed on target machine. >>>> >>>> We need further discussion how one is expected to provision a >>>> machine to run these tests. >>>> >>>> /Andy >>>> >>>>> >>>>> Otherwise looks fine. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>> Please review the fix to issue [1] at [2]. >>>>>> >>>>>> This change enables notarization on Mac for dmg images and >>>>>> app-image zip files. >>>>>> >>>>>> /Andy >>>>>> >>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>> >>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>> >>>>> > > > End of core-libs-dev Digest, Vol 156, Issue 12 > ********************************************** > From andy.herrick at oracle.com Fri Apr 3 15:31:19 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 3 Apr 2020 11:31:19 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg (Andy Herrick) In-Reply-To: References: Message-ID: On 4/3/2020 10:40 AM, James Elliott wrote: > This sounds promising! I just wanted to check if there is a mechanism to specify a custom set of entitlements needed by the application when running jpackage, in case it needs more than the normal set that Java itself does. Or does Java already ask for every possible entitlement in its original notarization? > > Thanks, > > -James Although there is an existing enhancement request JDK-8241448 to add a specific CLI to use different entitlements file, this code will give user ability to override entitlements without that CLI using the resource override mechanism as follows: Create a directory , (call it RESOURCE_DIR), add to that directory "APP_NAME.entitlements" file containing the entitlements you want then use the CLI options "--name APP_NAME --resource-dir RESOURCE_DIR. Then when signing APP_NAME this file will be used instead of the builtin resource entitlements.plist. /Andy > >> Date: Fri, 3 Apr 2020 10:20:21 -0400 >> From: Andy Herrick >> To: core-libs-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8237490: [macos] Add support notarizing jpackage >> app-image and dmg >> Message-ID: >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> sorry missing webrev pointer [4] >> >> [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 >> >> /Andy >> >> On 4/3/2020 9:24 AM, Andy Herrick wrote: >>> please review this revised webrev [4] to issue [2] >>> >>> The previous version generated a signed app that could be notarized, >>> but then couldn't run because signing the whole app resigned the >>> executable with reduced entitlements. >>> >>> This revision adds back in the entitlements when signing the whole >>> app, as well as fixing the unit test that was failing the spctl call >>> on Catalina due to signed app not being notarized. >>> >>> >>> /Andy >>> >>> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>>> revised with minor fixes as per below - webrev at [3] >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>>> >>>> /Andy >>>> >>>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>>> Hi Andy, >>>>>> >>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>>> >>>>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>>>> align with rest of code. >>>>> I will fix this. >>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>>> >>>>>> Line 70 - Capital F. >>>>> and this >>>>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>>>> will it work with older Xcode and macOS we planning to support? >>>>> not sure - may need some discussion of what we support and possible >>>>> conditional code here. >>>>>> Do we need any adjustments to signing tests we have? >>>>> The existing tests pass, but this is not unexpected (and really >>>>> means nothing) since the signing tests are all skipped unless >>>>> specific test certs are installed on target machine. >>>>> >>>>> We need further discussion how one is expected to provision a >>>>> machine to run these tests. >>>>> >>>>> /Andy >>>>> >>>>>> Otherwise looks fine. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>>> Please review the fix to issue [1] at [2]. >>>>>>> >>>>>>> This change enables notarization on Mac for dmg images and >>>>>>> app-image zip files. >>>>>>> >>>>>>> /Andy >>>>>>> >>>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>>> >>>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>>> >> >> End of core-libs-dev Digest, Vol 156, Issue 12 >> ********************************************** >> From roger.riggs at oracle.com Fri Apr 3 15:43:12 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 3 Apr 2020 11:43:12 -0400 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic Message-ID: Please review the CSR[1] and changes to remove the RMI static stub compiler (rmic). RMIC was deprecated for removal in JDK 13 [3]. The components modified are: ?- remove the jdk.rmic module ?- remove the jdk.rmic man page ?- remove all tests of rmic or relying on rmic ?- update or remove makefiles to remove references and dependencies on rmic ?- update source files in java.rmi module to remove extraneous references to rmic Wevrev: ? http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 Thanks, Roger [1] CSR: ? https://bugs.openjdk.java.net/browse/JDK-8242049 [2] Issue: ?https://bugs.openjdk.java.net/browse/JDK-8225319 [3] Deprecate rmic for removal ? ? https://bugs.openjdk.java.net/browse/JDK-8217412 From lance.andersen at oracle.com Fri Apr 3 16:10:11 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 3 Apr 2020 12:10:11 -0400 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: References: Message-ID: <303D0CB8-AADF-467C-B77A-CA5801B0F6E3@oracle.com> Hi Roger, This looks good and brought back memories of removing the Java EE modules :-) Best Lance > On Apr 3, 2020, at 11:43 AM, Roger Riggs wrote: > > Please review the CSR[1] and changes to remove the RMI static stub compiler (rmic). > RMIC was deprecated for removal in JDK 13 [3]. > > The components modified are: > - remove the jdk.rmic module > - remove the jdk.rmic man page > - remove all tests of rmic or relying on rmic > - update or remove makefiles to remove references and dependencies on rmic > - update source files in java.rmi module to remove extraneous references to rmic > > Wevrev: > http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 > > Thanks, Roger > > [1] CSR: > https://bugs.openjdk.java.net/browse/JDK-8242049 > > [2] Issue: > https://bugs.openjdk.java.net/browse/JDK-8225319 > > [3] Deprecate rmic for removal > https://bugs.openjdk.java.net/browse/JDK-8217412 > 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 Fri Apr 3 16:18:09 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Apr 2020 09:18:09 -0700 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: References: Message-ID: Looks good. /Erik On 2020-04-03 08:43, Roger Riggs wrote: > Please review the CSR[1] and changes to remove the RMI static stub > compiler (rmic). > RMIC was deprecated for removal in JDK 13 [3]. > > The components modified are: > ?- remove the jdk.rmic module > ?- remove the jdk.rmic man page > ?- remove all tests of rmic or relying on rmic > ?- update or remove makefiles to remove references and dependencies on > rmic > ?- update source files in java.rmi module to remove extraneous > references to rmic > > Wevrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 > > Thanks, Roger > > [1] CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8242049 > > [2] Issue: > ?https://bugs.openjdk.java.net/browse/JDK-8225319 > > [3] Deprecate rmic for removal > ? ? https://bugs.openjdk.java.net/browse/JDK-8217412 > From mandy.chung at oracle.com Fri Apr 3 21:32:48 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 3 Apr 2020 14:32:48 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Message-ID: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Hi Peter, I added a JBS comment [1] to describe this special case trying to put the story together (let me know if it needs more explanation). More comment inline below. On 4/3/20 4:40 AM, Peter Levart wrote: > Ok, I think I found one such use-case. In the following example: > > package test; > public class LambdaTest { > ??? protected void m() { > ??? } > } > > package test.sub; > public class LambdaTestSub extends test.LambdaTest { > ??? public void test() { > ??????? Runnable r = this::m; > ??????? r.run(); > ??? } > } Yes. This is specific for binary compatibility.?? the invocation of a protected method inherited from its supertype in a different package. The lambda proxy is in the same package as the target class (`test.sub` in the example above) but it has no access to `test.LambdaTest::m`. > > ...when compiled with JDK 14 javac. In this case the implClass is > test.sub.LambdaTestSub while implInfo is "invokeVirtual > test.LambdaTest.m:()void" and the method is not public. > In JDK 14, a lambda proxy `test.sub.LambdaTestSub\$Lambda\$\$1234` is VM anonymous class which has a special powerful access as if the host class.?? This proxy class, even though it's not an instance of `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` member. > Anyway, the name of the proxy class is derived from the targetClass > (and therefore shares the same package with targetClass) which is > caller's lookup class. Is targetClass always the same as implClass in > the invokeVirtual/invokeInterface case? > implMethod is the direct method handle describing the implementation method resolved by the VM.?? So it depends. In the above example, it's `test.LambdaTest.m:()void` and implClass is test.LambdaTest.? The targetClass is test.sub.LambdaTestSub which is *NOT* the same as implClass.? That's why we change if they are in the same package. It can be invoking a method in targetClass or a method in another class in the same package with package access, then implClass may or may not be the same as targetClass. > I also noticed that JDK 15 patched javac transforms method reference > in above code into a lambda method. But looking at the javac changes > in the patch, I don't quite see where this distinction between JDK 14 > and patched JDK 15 javac comes from. javac has been changed in JDK 14 to synthesize a bridge method if it's a method reference to access a protected member in a remote supertype? (JDK-8234729). BTW, the new tests relevant to this scenario are under test/jdk/java/lang/invoke/lambda/superProtectedMethod. > From the changes to method > com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: > > ??????????? final boolean needsConversionToLambda() { > ??????????????? return interfaceParameterIsIntersectionOrUnionType() || > ??????????????????????? isSuper || > ??????????????????????? needsVarArgsConversion() || > ??????????????????????? isArrayOp() || > #??????????????????????? isPrivateInOtherClass() || > isProtectedInSuperClassOfEnclosingClassInOtherPackage() || > ??????????????????????? !receiverAccessible() || > ??????????????????????? (tree.getMode() == ReferenceMode.NEW && > ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && > ????????????????????????? (tree.sym.owner.isLocal() || > tree.sym.owner.isInner())); > ??????????? } > > ...I would draw the conclusion that conversion to lambda is performed > in less cases not in more. Jan and Srikanath may be able to explain this further. > Hm. > > Regards, Peter > > On 4/3/20 11:11 AM, Peter Levart wrote: >> Hi Mandy, >> >> Good work. >> >> I'm trying to find out which language use-case is covered by the >> InnerClassLambdaMetafactory needing to inject method handle into the >> generated proxy class to be invoked instead of proxy class directly >> invoking the method: >> >> ??????? useImplMethodHandle = >> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >> ??????????????????????????????? && >> !Modifier.isPublic(implInfo.getModifiers()); >> >> If I check what implClass and implInfo get resolved to in >> AbstractValidatingLambdaMetafactory, there are several cases: >> >> ??????? this.implInfo = caller.revealDirect(implMethod); >> ??????? switch (implInfo.getReferenceKind()) { >> ??????????? case REF_invokeVirtual: >> ??????????? case REF_invokeInterface: >> ??????????????? this.implClass = implMethodType.parameterType(0); >> ??????????????? // reference kind reported by implInfo may not match >> implMethodType's first param >> ??????????????? // Example: implMethodType is (Cloneable)String, >> implInfo is for Object.toString >> ??????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? this.implIsInstanceMethod = true; >> ??????????????? break; >> ??????????? case REF_invokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here, but >> we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implIsInstanceMethod = true; >> >> ??????????????? // Classes compiled prior to dynamic nestmate support >> invokes a private instance >> ??????????????? // method with REF_invokeSpecial. >> ??????????????? // >> ??????????????? // invokespecial should only be used to invoke >> private nestmate constructors. >> ??????????????? // The lambda proxy class will be defined as a >> nestmate of targetClass. >> ??????????????? // If the method to be invoked is an instance method >> of targetClass, then >> ??????????????? // convert to use invokevirtual or invokeinterface. >> ??????????????? if (targetClass == implClass && >> !implInfo.getName().equals("")) { >> ??????????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? } else { >> ??????????????????? this.implKind = REF_invokeSpecial; >> ??????????????? } >> ??????????????? break; >> ??????????? case REF_invokeStatic: >> ??????????? case REF_newInvokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here for >> invokestatic, but we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implKind = implInfo.getReferenceKind(); >> ??????????????? this.implIsInstanceMethod = false; >> ??????????????? break; >> ??????????? default: >> ??????????????? throw new >> LambdaConversionException(String.format("Unsupported MethodHandle >> kind: %s", implInfo)); >> ??????? } >> >> >> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >> REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); >> >> Only REF_invokeVirtual and REF_invokeInterface are possible >> kandidates, right? >> >> So when does the implMethod type of parameter 0 differ from the >> declaring class of the MethodHandleInfo cracked from that same >> implMethod and in addition those two types leave in different packages? >> This is concerning the instance method and so parameter 0 is what it wants to look at. >> Regards, Peter >> Hope this helps. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 From alexander.matveev at oracle.com Fri Apr 3 23:29:14 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 3 Apr 2020 16:29:14 -0700 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> Message-ID: Hi Andy, http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html Maybe better to check for Catalina case as well, instead of disabling check. We can assume that on Catalina code 3 and not notarized will consider as pass. In case if it fails for some other reasons. Otherwise looks fine. Thanks, Alexander On 4/3/20 7:20 AM, Andy Herrick wrote: > sorry missing webrev pointer [4] > > [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 > > /Andy > > On 4/3/2020 9:24 AM, Andy Herrick wrote: >> please review this revised webrev [4] to issue [2] >> >> The previous version generated a signed app that could be notarized, >> but then couldn't run because signing the whole app resigned the >> executable with reduced entitlements. >> >> This revision adds back in the entitlements when signing the whole >> app, as well as fixing the unit test that was failing the spctl call >> on Catalina due to signed app not being notarized. >> >> >> /Andy >> >> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>> revised with minor fixes as per below - webrev at [3] >>> >>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>> >>> /Andy >>> >>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>> >>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>> Hi Andy, >>>>> >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>> >>>>> Line 819,857,902 - Looks like temp debug log message. Remove it or >>>>> align with rest of code. >>>> I will fix this. >>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>> >>>>> Line 70 - Capital F. >>>> and this >>>>> >>>>> Since we added "--timestamp" and? "--options runtime" to codesign, >>>>> will it work with older Xcode and macOS we planning to support? >>>> not sure - may need some discussion of what we support and possible >>>> conditional code here. >>>>> >>>>> Do we need any adjustments to signing tests we have? >>>> >>>> The existing tests pass, but this is not unexpected (and really >>>> means nothing) since the signing tests are all skipped unless >>>> specific test certs are installed on target machine. >>>> >>>> We need further discussion how one is expected to provision a >>>> machine to run these tests. >>>> >>>> /Andy >>>> >>>>> >>>>> Otherwise looks fine. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>> Please review the fix to issue [1] at [2]. >>>>>> >>>>>> This change enables notarization on Mac for dmg images and >>>>>> app-image zip files. >>>>>> >>>>>> /Andy >>>>>> >>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>> >>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>> >>>>> From sandhya.viswanathan at intel.com Sat Apr 4 00:16:57 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Sat, 4 Apr 2020 00:16:57 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes Message-ID: Hi, Following up on review requests of API [0], Java implementation [1] and General Hotspot changes[3] for Vector API, here's a request for review of x86 backend changes required for supporting the API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ Complete implementation resides in vector-unstable branch of panama/dev repository [3]. Looking forward to your feedback. Best Regards, Sandhya [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://openjdk.java.net/projects/panama/ \$ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From henry.jen at oracle.com Sat Apr 4 05:13:23 2020 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 3 Apr 2020 22:13:23 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> Message-ID: <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) > [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) > [2020-04-03T16:02:10,984Z] > [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) > [2020-04-03T16:02:11,051Z] > [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === > [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: > [2020-04-03T16:02:11,061Z] Undefined first referenced > [2020-04-03T16:02:11,061Z] symbol in file > [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o > [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors > [2020-04-03T16:02:11,082Z] > [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. > [2020-04-03T16:02:11,086Z] === End of repeated output === > [2020-04-03T16:02:11,094Z] > [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === > [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed > [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed > [2020-04-03T16:02:11,739Z] === End of repeated output === > [2020-04-03T16:02:11,741Z] I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. I?ll push [2] once I got a +1. [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ Cheers, Henry > On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: > > On 02/04/2020 11:26, linzang(??) wrote: >> : >> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >> Thanks for your help! >> > webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. > > -Alan. From linzang at tencent.com Sat Apr 4 05:51:30 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Sat, 4 Apr 2020 05:51:30 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> , <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> Message-ID: <46D23467-984D-40DA-B0C3-124B6E717FEB@tencent.com> Thanks Henry?[2] looks good to me! BRs, Lin > ? 2020?4?4????1:14?Henry Jen ??? > > ?Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) > >> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >> [2020-04-03T16:02:10,984Z] >> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >> [2020-04-03T16:02:11,051Z] >> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >> [2020-04-03T16:02:11,061Z] Undefined first referenced >> [2020-04-03T16:02:11,061Z] symbol in file >> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >> [2020-04-03T16:02:11,082Z] >> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >> [2020-04-03T16:02:11,086Z] === End of repeated output === >> [2020-04-03T16:02:11,094Z] >> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >> [2020-04-03T16:02:11,739Z] === End of repeated output === >> [2020-04-03T16:02:11,741Z] > > > I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. > > As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. > > I?ll push [2] once I got a +1. > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ > [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ > > Cheers, > Henry > >> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >> >>> On 02/04/2020 11:26, linzang(??) wrote: >>> : >>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>> Thanks for your help! >>> >> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >> >> -Alan. > > From peter.levart at gmail.com Sat Apr 4 10:58:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 12:58:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: Hi Mandy, On 4/3/20 11:32 PM, Mandy Chung wrote: > Hi Peter, > > I added a JBS comment [1] to describe this special case trying to put > the story together (let me know if it needs more explanation). ? More > comment inline below. Thanks, this helps in establishing the historical context. > > On 4/3/20 4:40 AM, Peter Levart wrote: >> Ok, I think I found one such use-case. In the following example: >> >> package test; >> public class LambdaTest { >> ??? protected void m() { >> ??? } >> } >> >> package test.sub; >> public class LambdaTestSub extends test.LambdaTest { >> ??? public void test() { >> ??????? Runnable r = this::m; >> ??????? r.run(); >> ??? } >> } > > Yes. > > This is specific for binary compatibility.?? the invocation of a > protected method inherited from its supertype in a different package. > > The lambda proxy is in the same package as the target class > (`test.sub` in the example above) but it has no access to > `test.LambdaTest::m`. > >> >> ...when compiled with JDK 14 javac. In this case the implClass is >> test.sub.LambdaTestSub while implInfo is "invokeVirtual >> test.LambdaTest.m:()void" and the method is not public. >> > > In JDK 14, a lambda proxy `test.sub.LambdaTestSub\$Lambda\$\$1234` is VM > anonymous class which has a special powerful access as if the host > class.?? This proxy class, even though it's not an instance of > `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` > member. Right, the VM anonymous class "inherits" all access rights from the host class, which in above example is the subclass of test.LambdaTes. > >> Anyway, the name of the proxy class is derived from the targetClass >> (and therefore shares the same package with targetClass) which is >> caller's lookup class. Is targetClass always the same as implClass in >> the invokeVirtual/invokeInterface case? >> > > implMethod is the direct method handle describing the implementation > method resolved by the VM.?? So it depends. > > In the above example, it's `test.LambdaTest.m:()void` and implClass is > test.LambdaTest. Here I think, you are not quite right. First I need to clarify that we are talking about the case where the method reference in above example is not converted to lambda by javac, so the proxy class needs to invoke the superclass method directly (without the help of lambda bridge). I did an experiment and compiled the example with JDK 13 javac, where the patch for (JDK-8234729) is not applied yet. What I get from this compilation is the following metafactory bootstrap method invocation: ? 0: #35 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles\$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; ??? Method arguments: ????? #42 ()V ????? #43 REF_invokeVirtual test/LambdaTest.m:()V ????? #42 ()V The #43 is the implMethod method handle and it is the following: ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual test/LambdaTest.m:()V ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V ? #45 = NameAndType??????? #46:#6???????? // m:()V ? #46 = Utf8?????????????? m ?? #2 = Class????????????? #4???????????? // test/LambdaTest ?? #4 = Utf8?????????????? test/LambdaTest *BUT* the class that looks up this MH from the constant pool is the subclass (test.sub.LambdaTestSub) which is equivalent to the following programmatic lookup: ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, "m", MethodType.methodType(void.class)); ??????? System.out.println(mh.type()); and this results in a method handle of the following type: (LambdaTestSub)void which is correct since the method handle *MUST* check that the passed in instance (this) is of type LambdaTestSub or subtype or else the "protected" access would be violated. And since the ref type is REF_invokeVirtual, the AbstractValidatingLambdaMetafactory assigns the following to the implClass: ??????? this.implMethodType = implMethod.type(); ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ...which makes the implClass be LambdaTestSub in this case. Which is correct again since we want InnerClassLambdaMetafactory to decide that this is the special case for proxy to invoke the method via method handle: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If implClass was test.LambdaTest as you said above, this condition would evaluate to false, since implInfo is "invokeVirtual test.LambdaTest.m:()void" in above case. So everything is OK, but my original question was the following: The name of the generated proxy class is derived from the targetClass which is the caller's lookup class. In this example the caller is LambdaTestSub and this is the same as implClass in this case. Would those two classes always be the same in the case where the evaluation of the above `useImplMethodHandle` boolean matters? I mean, the decision about whether to base the proxy invocation strategy on method handle or direct bytecode invocation is based on one class (implClass), but the actual package of the proxy class which effectively influences the bytecode invocation rights is taken from another class (targetClass). On one hand the package of the proxy class has to be the same as targetClass if the proxy wants to be the nestmate of the targetClass (for example to have private access to the members of the nest). But OTOH it needs to be the same package also with implClass so that the above decision of the proxy invocation strategy is correct. I have a feeling that for protected virtual methods, this is true, because the type of the 0-argument of such method handle is always the lookup class. But am I right? What do you think of another alternative to invoking the super protected method in other package: What if the LMF would decide to base the name of the proxy class on the implInfo.getDeclaringClass() in such case? It would not have to be a nestmate of any class, just in the same package with the method's declaring class. Consequently it would be in the same module as the declaring class and loaded by the same class loader. Therefore it would have to be WEAKLY referenced from the class loader. And the Lookup instance passed to bootstrap LMF method would not be enough for defining such class. But LMF could obtain special powers since it is JDK internal class... Well, I don't know for myself. Is this situation rare enough so that invoking via method handle is not a drawback? It only happens when running JDK 13- compiled classes with JDK 15+ and in addition the method reference must point to protected method in a distant class. > The targetClass is test.sub.LambdaTestSub which is *NOT* the same as > implClass.? That's why we change if they are in the same package. > > It can be invoking a method in targetClass or a method in another > class in the same package with package access, then implClass may or > may not be the same as targetClass. > >> I also noticed that JDK 15 patched javac transforms method reference >> in above code into a lambda method. But looking at the javac changes >> in the patch, I don't quite see where this distinction between JDK 14 >> and patched JDK 15 javac comes from. > > javac has been changed in JDK 14 to synthesize a bridge method if it's > a method reference to access a protected member in a remote supertype? > (JDK-8234729). Ah, that was the reason I haven't seen the change in your patch. I used the JDK 13 javac and thought it would be the same as JDK 14 javac. My mistake. So this answers the question below... Regards, Peter > > BTW, the new tests relevant to this scenario are under > test/jdk/java/lang/invoke/lambda/superProtectedMethod. > >> From the changes to method >> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >> >> ??????????? final boolean needsConversionToLambda() { >> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >> ??????????????????????? isSuper || >> ??????????????????????? needsVarArgsConversion() || >> ??????????????????????? isArrayOp() || >> #??????????????????????? isPrivateInOtherClass() || >> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >> ??????????????????????? !receiverAccessible() || >> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >> ????????????????????????? (tree.sym.owner.isLocal() || >> tree.sym.owner.isInner())); >> ??????????? } >> >> ...I would draw the conclusion that conversion to lambda is performed >> in less cases not in more. > > Jan and Srikanath may be able to explain this further. > >> Hm. >> >> Regards, Peter >> >> On 4/3/20 11:11 AM, Peter Levart wrote: >>> Hi Mandy, >>> >>> Good work. >>> >>> I'm trying to find out which language use-case is covered by the >>> InnerClassLambdaMetafactory needing to inject method handle into the >>> generated proxy class to be invoked instead of proxy class directly >>> invoking the method: >>> >>> ??????? useImplMethodHandle = >>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>> ??????????????????????????????? && >>> !Modifier.isPublic(implInfo.getModifiers()); >>> >>> If I check what implClass and implInfo get resolved to in >>> AbstractValidatingLambdaMetafactory, there are several cases: >>> >>> ??????? this.implInfo = caller.revealDirect(implMethod); >>> ??????? switch (implInfo.getReferenceKind()) { >>> ??????????? case REF_invokeVirtual: >>> ??????????? case REF_invokeInterface: >>> ??????????????? this.implClass = implMethodType.parameterType(0); >>> ??????????????? // reference kind reported by implInfo may not match >>> implMethodType's first param >>> ??????????????? // Example: implMethodType is (Cloneable)String, >>> implInfo is for Object.toString >>> ??????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? this.implIsInstanceMethod = true; >>> ??????????????? break; >>> ??????????? case REF_invokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here, >>> but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implIsInstanceMethod = true; >>> >>> ??????????????? // Classes compiled prior to dynamic nestmate >>> support invokes a private instance >>> ??????????????? // method with REF_invokeSpecial. >>> ??????????????? // >>> ??????????????? // invokespecial should only be used to invoke >>> private nestmate constructors. >>> ??????????????? // The lambda proxy class will be defined as a >>> nestmate of targetClass. >>> ??????????????? // If the method to be invoked is an instance method >>> of targetClass, then >>> ??????????????? // convert to use invokevirtual or invokeinterface. >>> ??????????????? if (targetClass == implClass && >>> !implInfo.getName().equals("")) { >>> ??????????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? } else { >>> ??????????????????? this.implKind = REF_invokeSpecial; >>> ??????????????? } >>> ??????????????? break; >>> ??????????? case REF_invokeStatic: >>> ??????????? case REF_newInvokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here for >>> invokestatic, but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>> ??????????????? this.implIsInstanceMethod = false; >>> ??????????????? break; >>> ??????????? default: >>> ??????????????? throw new >>> LambdaConversionException(String.format("Unsupported MethodHandle >>> kind: %s", implInfo)); >>> ??????? } >>> >>> >>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>> REF_newInvokeSpecial) the this.implClass = >>> implInfo.getDeclaringClass(); >>> >>> Only REF_invokeVirtual and REF_invokeInterface are possible >>> kandidates, right? >>> >>> So when does the implMethod type of parameter 0 differ from the >>> declaring class of the MethodHandleInfo cracked from that same >>> implMethod and in addition those two types leave in different packages? >>> > > This is concerning the instance method and so parameter 0 is what it > wants to look at. > >>> Regards, Peter >>> > > Hope this helps. > Mandy > [1] > https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 > > From andy.herrick at oracle.com Sat Apr 4 12:53:22 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 4 Apr 2020 08:53:22 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> Message-ID: <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> I think it best to modify these checks as part of a separate issue, and leave these checks disabled as part of JDK-8237490.? I have filed JDK-8242155 to enhance these tests, including restoring these checks. /ANdy On 4/3/2020 7:29 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html > > Maybe better to check for Catalina case as well, instead of disabling > check. We can assume that on Catalina code 3 and not notarized will > consider as pass. In case if it fails for some other reasons. > > Otherwise looks fine. > > Thanks, > Alexander > > On 4/3/20 7:20 AM, Andy Herrick wrote: >> sorry missing webrev pointer [4] >> >> [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 >> >> /Andy >> >> On 4/3/2020 9:24 AM, Andy Herrick wrote: >>> please review this revised webrev [4] to issue [2] >>> >>> The previous version generated a signed app that could be notarized, >>> but then couldn't run because signing the whole app resigned the >>> executable with reduced entitlements. >>> >>> This revision adds back in the entitlements when signing the whole >>> app, as well as fixing the unit test that was failing the spctl call >>> on Catalina due to signed app not being notarized. >>> >>> >>> /Andy >>> >>> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>>> revised with minor fixes as per below - webrev at [3] >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>>> >>>> /Andy >>>> >>>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>>> >>>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>>> Hi Andy, >>>>>> >>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>>> >>>>>> Line 819,857,902 - Looks like temp debug log message. Remove it >>>>>> or align with rest of code. >>>>> I will fix this. >>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>>> >>>>>> Line 70 - Capital F. >>>>> and this >>>>>> >>>>>> Since we added "--timestamp" and? "--options runtime" to >>>>>> codesign, will it work with older Xcode and macOS we planning to >>>>>> support? >>>>> not sure - may need some discussion of what we support and >>>>> possible conditional code here. >>>>>> >>>>>> Do we need any adjustments to signing tests we have? >>>>> >>>>> The existing tests pass, but this is not unexpected (and really >>>>> means nothing) since the signing tests are all skipped unless >>>>> specific test certs are installed on target machine. >>>>> >>>>> We need further discussion how one is expected to provision a >>>>> machine to run these tests. >>>>> >>>>> /Andy >>>>> >>>>>> >>>>>> Otherwise looks fine. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>>> Please review the fix to issue [1] at [2]. >>>>>>> >>>>>>> This change enables notarization on Mac for dmg images and >>>>>>> app-image zip files. >>>>>>> >>>>>>> /Andy >>>>>>> >>>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>>> >>>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>>> >>>>>> > From peter.levart at gmail.com Sat Apr 4 16:16:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 18:16:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Hi Mandy, Just another observation of the code in InnerClassLambdaMetafactory... For the useImplMethodHandle case you generate the protectedImplMethod static field to hold the MH and a static setter method: ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, ??????????????????????????????? null, null); ...but then later after you define the class you inject the MH via a "staticSetter" method handle: ??????????????? MethodHandle mh = lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, MethodHandle.class); ??????????????? mh.invokeExact(implMethod); So you don't invoke the generated setter method but set the field via special kind of method handle (equivalent to putstatic bytecode). You can remove the setImplMethod method generation code. Regards, Peter On 4/4/20 12:58 PM, Peter Levart wrote: > Hi Mandy, > > On 4/3/20 11:32 PM, Mandy Chung wrote: >> Hi Peter, >> >> I added a JBS comment [1] to describe this special case trying to put >> the story together (let me know if it needs more explanation). ? More >> comment inline below. > > Thanks, this helps in establishing the historical context. > >> >> On 4/3/20 4:40 AM, Peter Levart wrote: >>> Ok, I think I found one such use-case. In the following example: >>> >>> package test; >>> public class LambdaTest { >>> ??? protected void m() { >>> ??? } >>> } >>> >>> package test.sub; >>> public class LambdaTestSub extends test.LambdaTest { >>> ??? public void test() { >>> ??????? Runnable r = this::m; >>> ??????? r.run(); >>> ??? } >>> } >> >> Yes. >> >> This is specific for binary compatibility.?? the invocation of a >> protected method inherited from its supertype in a different package. >> >> The lambda proxy is in the same package as the target class >> (`test.sub` in the example above) but it has no access to >> `test.LambdaTest::m`. >> >>> >>> ...when compiled with JDK 14 javac. In this case the implClass is >>> test.sub.LambdaTestSub while implInfo is "invokeVirtual >>> test.LambdaTest.m:()void" and the method is not public. >>> >> >> In JDK 14, a lambda proxy `test.sub.LambdaTestSub\$Lambda\$\$1234` is VM >> anonymous class which has a special powerful access as if the host >> class.?? This proxy class, even though it's not an instance of >> `test.LambdaTest`, can invoke? the >> protected`test.LambdaTest.m:()void` member. > > Right, the VM anonymous class "inherits" all access rights from the > host class, which in above example is the subclass of test.LambdaTes. > >> >>> Anyway, the name of the proxy class is derived from the targetClass >>> (and therefore shares the same package with targetClass) which is >>> caller's lookup class. Is targetClass always the same as implClass >>> in the invokeVirtual/invokeInterface case? >>> >> >> implMethod is the direct method handle describing the implementation >> method resolved by the VM.?? So it depends. >> >> In the above example, it's `test.LambdaTest.m:()void` and implClass >> is test.LambdaTest. > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles\$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Would > those two classes always be the same in the case where the evaluation > of the above `useImplMethodHandle` boolean matters? I mean, the > decision about whether to base the proxy invocation strategy on method > handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. > >> The targetClass is test.sub.LambdaTestSub which is *NOT* the same as >> implClass.? That's why we change if they are in the same package. >> >> It can be invoking a method in targetClass or a method in another >> class in the same package with package access, then implClass may or >> may not be the same as targetClass. >> >>> I also noticed that JDK 15 patched javac transforms method reference >>> in above code into a lambda method. But looking at the javac changes >>> in the patch, I don't quite see where this distinction between JDK >>> 14 and patched JDK 15 javac comes from. >> >> javac has been changed in JDK 14 to synthesize a bridge method if >> it's a method reference to access a protected member in a remote >> supertype? (JDK-8234729). > > Ah, that was the reason I haven't seen the change in your patch. I > used the JDK 13 javac and thought it would be the same as JDK 14 > javac. My mistake. > > So this answers the question below... > > > Regards, Peter > >> >> BTW, the new tests relevant to this scenario are under >> test/jdk/java/lang/invoke/lambda/superProtectedMethod. >> >>> From the changes to method >>> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >>> >>> ??????????? final boolean needsConversionToLambda() { >>> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >>> ??????????????????????? isSuper || >>> ??????????????????????? needsVarArgsConversion() || >>> ??????????????????????? isArrayOp() || >>> #??????????????????????? isPrivateInOtherClass() || >>> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >>> ??????????????????????? !receiverAccessible() || >>> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >>> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >>> ????????????????????????? (tree.sym.owner.isLocal() || >>> tree.sym.owner.isInner())); >>> ??????????? } >>> >>> ...I would draw the conclusion that conversion to lambda is >>> performed in less cases not in more. >> >> Jan and Srikanath may be able to explain this further. >> >>> Hm. >>> >>> Regards, Peter >>> >>> On 4/3/20 11:11 AM, Peter Levart wrote: >>>> Hi Mandy, >>>> >>>> Good work. >>>> >>>> I'm trying to find out which language use-case is covered by the >>>> InnerClassLambdaMetafactory needing to inject method handle into >>>> the generated proxy class to be invoked instead of proxy class >>>> directly invoking the method: >>>> >>>> ??????? useImplMethodHandle = >>>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>>> ??????????????????????????????? && >>>> !Modifier.isPublic(implInfo.getModifiers()); >>>> >>>> If I check what implClass and implInfo get resolved to in >>>> AbstractValidatingLambdaMetafactory, there are several cases: >>>> >>>> ??????? this.implInfo = caller.revealDirect(implMethod); >>>> ??????? switch (implInfo.getReferenceKind()) { >>>> ??????????? case REF_invokeVirtual: >>>> ??????????? case REF_invokeInterface: >>>> ??????????????? this.implClass = implMethodType.parameterType(0); >>>> ??????????????? // reference kind reported by implInfo may not >>>> match implMethodType's first param >>>> ??????????????? // Example: implMethodType is (Cloneable)String, >>>> implInfo is for Object.toString >>>> ??????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? this.implIsInstanceMethod = true; >>>> ??????????????? break; >>>> ??????????? case REF_invokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here, >>>> but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implIsInstanceMethod = true; >>>> >>>> ??????????????? // Classes compiled prior to dynamic nestmate >>>> support invokes a private instance >>>> ??????????????? // method with REF_invokeSpecial. >>>> ??????????????? // >>>> ??????????????? // invokespecial should only be used to invoke >>>> private nestmate constructors. >>>> ??????????????? // The lambda proxy class will be defined as a >>>> nestmate of targetClass. >>>> ??????????????? // If the method to be invoked is an instance >>>> method of targetClass, then >>>> ??????????????? // convert to use invokevirtual or invokeinterface. >>>> ??????????????? if (targetClass == implClass && >>>> !implInfo.getName().equals("")) { >>>> ??????????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? } else { >>>> ??????????????????? this.implKind = REF_invokeSpecial; >>>> ??????????????? } >>>> ??????????????? break; >>>> ??????????? case REF_invokeStatic: >>>> ??????????? case REF_newInvokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here >>>> for invokestatic, but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>>> ??????????????? this.implIsInstanceMethod = false; >>>> ??????????????? break; >>>> ??????????? default: >>>> ??????????????? throw new >>>> LambdaConversionException(String.format("Unsupported MethodHandle >>>> kind: %s", implInfo)); >>>> ??????? } >>>> >>>> >>>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>>> REF_newInvokeSpecial) the this.implClass = >>>> implInfo.getDeclaringClass(); >>>> >>>> Only REF_invokeVirtual and REF_invokeInterface are possible >>>> kandidates, right? >>>> >>>> So when does the implMethod type of parameter 0 differ from the >>>> declaring class of the MethodHandleInfo cracked from that same >>>> implMethod and in addition those two types leave in different >>>> packages? >>>> >> >> This is concerning the instance method and so parameter 0 is what it >> wants to look at. >> >>>> Regards, Peter >>>> >> >> Hope this helps. >> Mandy >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 >> >> > From mandy.chung at oracle.com Sat Apr 4 16:45:20 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 09:45:20 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Message-ID: <53d28cd4-8e4e-b1bb-f218-a9f382ea9df6@oracle.com> On 4/4/20 9:16 AM, Peter Levart wrote: > Hi Mandy, > > Just another observation of the code in InnerClassLambdaMetafactory... > > For the useImplMethodHandle case you generate the protectedImplMethod > static field to hold the MH and a static setter method: > > ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, > ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, > ??????????????????????????????? null, null); > > ...but then later after you define the class you inject the MH via a > "staticSetter" method handle: > > ??????????????? MethodHandle mh = > lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, > MethodHandle.class); > ??????????????? mh.invokeExact(implMethod); > > So you don't invoke the generated setter method but set the field via > special kind of method handle (equivalent to putstatic bytecode). > You can remove the setImplMethod method generation code. > Good catch.?? Removed the unused method. Mandy > Regards, Peter From mandy.chung at oracle.com Sat Apr 4 18:15:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 11:15:14 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <5fb01f1d-7d4d-b024-095a-4f429b2a06af@oracle.com> Hi Peter, On 4/4/20 3:58 AM, Peter Levart wrote: > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles\$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > My bad.? I mixed up with implClass and implInfo cracked from implMethod in your question. implInfo::getDeclaringClass() returns the declaring class of the resolved method, which is the superclass (which is what I have been thinking for test.LambdaTest). implClass is the target type of the method reference. AbstractValidatingLambdaMetafactory has clear comment: ??? final MethodType implMethodType;? // Type of the implMethod MethodHandle "(CC,int)String" ??? final Class implClass;???????????????? // Class for referencing the implementation method "class CC" > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Yes. > Would those two classes always be the same in the case where the > evaluation of the above `useImplMethodHandle` boolean matters? I mean, > the decision about whether to base the proxy invocation strategy on > method handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > The implementation of the method reference invocation is logical part of the caller class.? I don't think spinning the proxy class in a remote package is the desirable thing to do (injecting a class from package A to package B). > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. There are other alternatives we considered.? This implementation is a just short term solution.? We plan to follow up some future enhancements that are the possible longer-term solutions for this issue. 1. JDK-8239580 evaluate the performance of direct method handle invocation rather than bytecode invocation for ALL cases Direct invocation of the `implMethod` method handle by the lambda proxy was explored in JDK 8 lambda development time. It is time to remeasure the performance of direct method handle invocation and re-evaluate that approach. 2.? JDK-8230501 class data support.? The live MethodHandle can be passed to the hidden class to replace the current implementation to set the implMethod in a static field of proxy class after it's defined. 3. JDK-8199386 enhance Lookup::in to support nestmates Hope this helps. Mandy From christoph.dreis at freenet.de Sun Apr 5 08:57:18 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Sun, 05 Apr 2020 10:57:18 +0200 Subject: [NEW BUG] Small optimization in URLStreamHandler.parseURL Message-ID: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> Hi, I just noticed a small optimization opportunity in URLStreamHandler.parseURL for inputs like the following: new URL(new URL("file:"), "file:./path/to/some/local.properties"); In those cases there is no authority involved, which makes it possible to rewrite URLStreamHandler:L269-270: String separator = (authority != null) ? "/" : ""; path = separator + spec.substring(start, limit); into the following to avoid unnecessary string concatenations with an empty string: path = spec.substring(start, limit); path = (authority != null) ? "/" + path : path; I've written a small benchmark with two URLStreamHandler variants (one with the old parseURL and one with the new): @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private URL context; private URLStreamHandler newHandler = new NewURLStreamHandler(); private URLStreamHandler oldHandler = new OldURLStreamHandler(); private String spec = "file:./path/to/some/application.properties"; public ThreadState() { try { context = new URL("file:"); } catch (MalformedURLException ignored) { } } } @Benchmark public URL testNew(ThreadState threadState) throws MalformedURLException { return new URL(threadState.context, threadState.spec, threadState.newHandler); } @Benchmark public URL testOld(ThreadState threadState) throws MalformedURLException { return new URL(threadState.context, threadState.spec, threadState.oldHandler); } } The benchmark above yields the following results on my local machine: Benchmark Mode Cnt Score Error Units MyBenchmark.testNew avgt 10 112,655 ? 3,494 ns/op MyBenchmark.testNew:?gc.alloc.rate avgt 10 1299,558 ? 41,238 MB/sec MyBenchmark.testNew:?gc.alloc.rate.norm avgt 10 192,015 ? 0,003 B/op MyBenchmark.testNew:?gc.count avgt 10 98,000 counts MyBenchmark.testNew:?gc.time avgt 10 105,000 ms MyBenchmark.testOld avgt 10 128,592 ? 1,183 ns/op MyBenchmark.testOld:?gc.alloc.rate avgt 10 1612,743 ? 15,792 MB/sec MyBenchmark.testOld:?gc.alloc.rate.norm avgt 10 272,019 ? 0,001 B/op MyBenchmark.testOld:?gc.count avgt 10 110,000 counts MyBenchmark.testOld:?gc.time avgt 10 121,000 ms In case you think this is worthwhile I would need someone to sponsor the attached patch for me. I would highly appreciate that. Cheers, Christoph ===== PATCH ===== diff --git a/src/java.base/share/classes/java/net/URLStreamHandler.java b/src/java.base/share/classes/java/net/URLStreamHandler.java --- a/src/java.base/share/classes/java/net/URLStreamHandler.java +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java @@ -266,8 +266,8 @@ spec.substring(start, limit); } else { - String separator = (authority != null) ? "/" : ""; - path = separator + spec.substring(start, limit); + path = spec.substring(start, limit); + path = (authority != null) ? "/" + path : path; } } else if (queryOnly && path != null) { int ind = path.lastIndexOf('/'); From david.holmes at oracle.com Sun Apr 5 13:17:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 5 Apr 2020 23:17:18 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> Message-ID: On 4/04/2020 3:13 pm, Henry Jen wrote: > Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) The problem is in defining that function as inline rather than the -DHAVE_GETHRTIME. >> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) The build rules for this special test launcher need to be examined as something seems wrong to me. David ----- >> [2020-04-03T16:02:10,984Z] >> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >> [2020-04-03T16:02:11,051Z] >> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >> [2020-04-03T16:02:11,061Z] Undefined first referenced >> [2020-04-03T16:02:11,061Z] symbol in file >> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >> [2020-04-03T16:02:11,082Z] >> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >> [2020-04-03T16:02:11,086Z] === End of repeated output === >> [2020-04-03T16:02:11,094Z] >> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >> [2020-04-03T16:02:11,739Z] === End of repeated output === >> [2020-04-03T16:02:11,741Z] > > > I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. > > As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. > > I?ll push [2] once I got a +1. > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ > [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ > > Cheers, > Henry > >> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >> >> On 02/04/2020 11:26, linzang(??) wrote: >>> : >>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>> Thanks for your help! >>> >> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >> >> -Alan. > From Alan.Bateman at oracle.com Sun Apr 5 13:52:53 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 5 Apr 2020 14:52:53 +0100 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> Message-ID: <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> On 05/04/2020 14:17, David Holmes wrote: > On 4/04/2020 3:13 pm, Henry Jen wrote: >> Internal test shows that inline implementation is not working for >> some Solaris artifacts, because the -DHAVE_GETHRTIME is not >> consistently defined, so it is actually broken. :) > > The problem is in defining that function as inline rather than the > -DHAVE_GETHRTIME. > >>> [2020-04-03T15:59:26,981Z] Creating >>> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) > > The build rules for this special test launcher need to be examined as > something seems wrong to me. I assume it's just that it's just compiled differently to the regular launchers and just not noticed that it was missing -DHAVE_GETHRTIME (unless for anyone to use it with _JAVA_LAUNCHER_DEBUG set). If we go with Henry's second webrev then I assume -DHAVE_GETHRTIME can be dropped from LauncherCommon.gmk to avoid confusing any further maintainers in this area. Also is there a strong need for the non-Solaris getTimeMicros to have be inline? -Alan From claes.redestad at oracle.com Sun Apr 5 17:48:52 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 5 Apr 2020 19:48:52 +0200 Subject: [NEW BUG] Small optimization in URLStreamHandler.parseURL In-Reply-To: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> Message-ID: Hi Christoph, looks good and trivial. I'll sponsor. /Claes On 2020-04-05 10:57, Christoph Dreis wrote: > Hi, > > I just noticed a small optimization opportunity in URLStreamHandler.parseURL for inputs like the following: > > new URL(new URL("file:"), "file:./path/to/some/local.properties"); > > In those cases there is no authority involved, which makes it possible to rewrite URLStreamHandler:L269-270: > > String separator = (authority != null) ? "/" : ""; > path = separator + spec.substring(start, limit); > > into the following to avoid unnecessary string concatenations with an empty string: > > path = spec.substring(start, limit); > path = (authority != null) ? "/" + path : path; > > I've written a small benchmark with two URLStreamHandler variants (one with the old parseURL and one with the new): > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private URL context; > private URLStreamHandler newHandler = new NewURLStreamHandler(); > private URLStreamHandler oldHandler = new OldURLStreamHandler(); > private String spec = "file:./path/to/some/application.properties"; > > public ThreadState() { > try { > context = new URL("file:"); > } catch (MalformedURLException ignored) { > > } > } > } > > @Benchmark > public URL testNew(ThreadState threadState) throws MalformedURLException { > return new URL(threadState.context, threadState.spec, threadState.newHandler); > } > > @Benchmark > public URL testOld(ThreadState threadState) throws MalformedURLException { > return new URL(threadState.context, threadState.spec, threadState.oldHandler); > } > > } > > The benchmark above yields the following results on my local machine: > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testNew avgt 10 112,655 ? 3,494 ns/op > MyBenchmark.testNew:?gc.alloc.rate avgt 10 1299,558 ? 41,238 MB/sec > MyBenchmark.testNew:?gc.alloc.rate.norm avgt 10 192,015 ? 0,003 B/op > MyBenchmark.testNew:?gc.count avgt 10 98,000 counts > MyBenchmark.testNew:?gc.time avgt 10 105,000 ms > MyBenchmark.testOld avgt 10 128,592 ? 1,183 ns/op > MyBenchmark.testOld:?gc.alloc.rate avgt 10 1612,743 ? 15,792 MB/sec > MyBenchmark.testOld:?gc.alloc.rate.norm avgt 10 272,019 ? 0,001 B/op > MyBenchmark.testOld:?gc.count avgt 10 110,000 counts > MyBenchmark.testOld:?gc.time avgt 10 121,000 ms > > > In case you think this is worthwhile I would need someone to sponsor the attached patch for me. > I would highly appreciate that. > > Cheers, > Christoph > > > ===== PATCH ===== > diff --git a/src/java.base/share/classes/java/net/URLStreamHandler.java b/src/java.base/share/classes/java/net/URLStreamHandler.java > --- a/src/java.base/share/classes/java/net/URLStreamHandler.java > +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java > @@ -266,8 +266,8 @@ > spec.substring(start, limit); > > } else { > - String separator = (authority != null) ? "/" : ""; > - path = separator + spec.substring(start, limit); > + path = spec.substring(start, limit); > + path = (authority != null) ? "/" + path : path; > } > } else if (queryOnly && path != null) { > int ind = path.lastIndexOf('/'); > > From henry.jen at oracle.com Sun Apr 5 19:36:06 2020 From: henry.jen at oracle.com (Henry Jen) Date: Sun, 5 Apr 2020 12:36:06 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> Message-ID: <806519A8-191B-47AA-84B8-BB099672F311@oracle.com> > On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote: > > > On 05/04/2020 14:17, David Holmes wrote: >> On 4/04/2020 3:13 pm, Henry Jen wrote: >>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >> >> The problem is in defining that function as inline rather than the -DHAVE_GETHRTIME. >> >>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >> >> The build rules for this special test launcher need to be examined as something seems wrong to me. > I assume it's just that it's just compiled differently to the regular launchers and just not noticed that it was missing -DHAVE_GETHRTIME (unless for anyone to use it with _JAVA_LAUNCHER_DEBUG set). This is my understanding as well, we built something without define -DHAVA_GETHRTIME but linked with the library that was built with that defined and use inline function. We won?t notice this before because CounterGet is no-op before. > If we go with Henry's second webrev then I assume -DHAVE_GETHRTIME can be dropped from LauncherCommon.gmk to avoid confusing any further maintainers in this area. Right, I can drop that as well. > Also is there a strong need for the non-Solaris getTimeMicros to have be inline? > Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. Cheers, Henry From vipinsharma85 at gmail.com Sun Apr 5 20:42:52 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Mon, 6 Apr 2020 02:12:52 +0530 Subject: Need sponsor to fix Javadoc warnings Message-ID: Hi, I have fixed a few warnings where the method parameter name is different in code and Javadoc, need a sponsor for this patch. Webrev is available at https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e Regards, Vipin From david.holmes at oracle.com Sun Apr 5 21:55:15 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 07:55:15 +1000 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: Message-ID: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> Hi Vipin, On 6/04/2020 6:42 am, Vipin Sharma wrote: > Hi, > > I have fixed a few warnings where the method parameter name is different in > code and Javadoc, need a sponsor for this patch. > Webrev is available at > https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. Thanks, David > Regards, > Vipin > From linzang at tencent.com Mon Apr 6 00:53:04 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 6 Apr 2020 00:53:04 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <806519A8-191B-47AA-84B8-BB099672F311@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> <806519A8-191B-47AA-84B8-BB099672F311@oracle.com> Message-ID: <2CDF989E-B5FA-49D0-99FA-EF644B4BBA9A@tencent.com> > Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. How about use macro instead of function? +#define getTimeMicros() ({ \ + uint64_t result = 0; \ + struct timeval tv; \ + if (gettimeofday(&tv, NULL) != -1) { \ + result = 1000000LL * (uint64_t)tv.tv_sec; \ + result += (uint64_t)tv.tv_usec; \ + } \ + result; \ +}) I have tested it works on linux, not sure whether it is ok for solaris. BRs, Lin ?On 2020/4/6, 3:37 AM, "Henry Jen" wrote: > On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote: > > > On 05/04/2020 14:17, David Holmes wrote: >> On 4/04/2020 3:13 pm, Henry Jen wrote: >>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >> >> The problem is in defining that function as inline rather than the -DHAVE_GETHRTIME. >> >>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >> >> The build rules for this special test launcher need to be examined as something seems wrong to me. > I assume it's just that it's just compiled differently to the regular launchers and just not noticed that it was missing -DHAVE_GETHRTIME (unless for anyone to use it with _JAVA_LAUNCHER_DEBUG set). This is my understanding as well, we built something without define -DHAVA_GETHRTIME but linked with the library that was built with that defined and use inline function. We won?t notice this before because CounterGet is no-op before. > If we go with Henry's second webrev then I assume -DHAVE_GETHRTIME can be dropped from LauncherCommon.gmk to avoid confusing any further maintainers in this area. Right, I can drop that as well. > Also is there a strong need for the non-Solaris getTimeMicros to have be inline? > Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. Cheers, Henry From david.holmes at oracle.com Mon Apr 6 01:28:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 11:28:11 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <2CDF989E-B5FA-49D0-99FA-EF644B4BBA9A@tencent.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> <806519A8-191B-47AA-84B8-BB099672F311@oracle.com> <2CDF989E-B5FA-49D0-99FA-EF644B4BBA9A@tencent.com> Message-ID: <767c4dd3-2f05-7f0f-833c-8f6ad946115c@oracle.com> On 6/04/2020 10:53 am, linzang(??) wrote: >> Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. > > How about use macro instead of function? No that's not appropriate use of a macro. This is a full function, if inlining may be problematic (and I agree the inlining may not be a problem afterall) then it should declared in the header file and defined in java_md_solinux.c David > +#define getTimeMicros() ({ \ > + uint64_t result = 0; \ > + struct timeval tv; \ > + if (gettimeofday(&tv, NULL) != -1) { \ > + result = 1000000LL * (uint64_t)tv.tv_sec; \ > + result += (uint64_t)tv.tv_usec; \ > + } \ > + result; \ > +}) > > I have tested it works on linux, not sure whether it is ok for solaris. > > BRs, > Lin > > ?On 2020/4/6, 3:37 AM, "Henry Jen" wrote: > > > > > On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote: > > > > > > On 05/04/2020 14:17, David Holmes wrote: > >> On 4/04/2020 3:13 pm, Henry Jen wrote: > >>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) > >> > >> The problem is in defining that function as inline rather than the -DHAVE_GETHRTIME. > >> > >>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) > >> > >> The build rules for this special test launcher need to be examined as something seems wrong to me. > > I assume it's just that it's just compiled differently to the regular launchers and just not noticed that it was missing -DHAVE_GETHRTIME (unless for anyone to use it with _JAVA_LAUNCHER_DEBUG set). > > This is my understanding as well, we built something without define -DHAVA_GETHRTIME but linked with the library that was built with that defined and use inline function. We won?t notice this before because CounterGet is no-op before. > > > If we go with Henry's second webrev then I assume -DHAVE_GETHRTIME can be dropped from LauncherCommon.gmk to avoid confusing any further maintainers in this area. > > Right, I can drop that as well. > > > Also is there a strong need for the non-Solaris getTimeMicros to have be inline? > > > > Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. > > Cheers, > Henry > > > > From linzang at tencent.com Mon Apr 6 01:46:07 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 6 Apr 2020 01:46:07 +0000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <767c4dd3-2f05-7f0f-833c-8f6ad946115c@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <83b2a4cc-8c70-a442-8c64-53aed6a91d0f@oracle.com> <806519A8-191B-47AA-84B8-BB099672F311@oracle.com> <2CDF989E-B5FA-49D0-99FA-EF644B4BBA9A@tencent.com>, <767c4dd3-2f05-7f0f-833c-8f6ad946115c@oracle.com> Message-ID: <7C1B1FEE-75F0-4C91-9AF3-577CD65BBAFF@tencent.com> Agree?I also think inline may not be a problem. The reason I used inline is to avoid touching java_md_linux.c. BRs? Lin > ? 2020?4?6????9:31?David Holmes ??? > > ?On 6/04/2020 10:53 am, linzang(??) wrote: >>> Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. >> How about use macro instead of function? > > No that's not appropriate use of a macro. This is a full function, if inlining may be problematic (and I agree the inlining may not be a problem afterall) then it should declared in the header file and defined in java_md_solinux.c > > David > >> +#define getTimeMicros() ({ \ >> + uint64_t result = 0; \ >> + struct timeval tv; \ >> + if (gettimeofday(&tv, NULL) != -1) { \ >> + result = 1000000LL * (uint64_t)tv.tv_sec; \ >> + result += (uint64_t)tv.tv_usec; \ >> + } \ >> + result; \ >> +}) >> I have tested it works on linux, not sure whether it is ok for solaris. >> BRs, >> Lin >> ?On 2020/4/6, 3:37 AM, "Henry Jen" wrote: >> > On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote: >> > >> > >> > On 05/04/2020 14:17, David Holmes wrote: >> >> On 4/04/2020 3:13 pm, Henry Jen wrote: >> >>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >> >> >> >> The problem is in defining that function as inline rather than the -DHAVE_GETHRTIME. >> >> >> >>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >> >> >> >> The build rules for this special test launcher need to be examined as something seems wrong to me. >> > I assume it's just that it's just compiled differently to the regular launchers and just not noticed that it was missing -DHAVE_GETHRTIME (unless for anyone to use it with _JAVA_LAUNCHER_DEBUG set). >> This is my understanding as well, we built something without define -DHAVA_GETHRTIME but linked with the library that was built with that defined and use inline function. We won?t notice this before because CounterGet is no-op before. >> > If we go with Henry's second webrev then I assume -DHAVE_GETHRTIME can be dropped from LauncherCommon.gmk to avoid confusing any further maintainers in this area. >> Right, I can drop that as well. >> > Also is there a strong need for the non-Solaris getTimeMicros to have be inline? >> > >> Certainly we can change to not inline by combining both fixes. I don?t think inline is necessary causing problem but that means header and the binary does need to match. >> Cheers, >> Henry >> > From david.holmes at oracle.com Mon Apr 6 01:50:07 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 11:50:07 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> Message-ID: <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> There is something not right here ... On 4/04/2020 3:13 pm, Henry Jen wrote: > Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) > >> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >> [2020-04-03T16:02:10,984Z] >> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >> [2020-04-03T16:02:11,051Z] >> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >> [2020-04-03T16:02:11,061Z] Undefined first referenced >> [2020-04-03T16:02:11,061Z] symbol in file >> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. David ----- >> [2020-04-03T16:02:11,082Z] >> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >> [2020-04-03T16:02:11,086Z] === End of repeated output === >> [2020-04-03T16:02:11,094Z] >> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >> [2020-04-03T16:02:11,739Z] === End of repeated output === >> [2020-04-03T16:02:11,741Z] > > > I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. > > As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. > > I?ll push [2] once I got a +1. > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ > [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ > > Cheers, > Henry > >> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >> >> On 02/04/2020 11:26, linzang(??) wrote: >>> : >>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>> Thanks for your help! >>> >> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >> >> -Alan. > From david.holmes at oracle.com Mon Apr 6 02:15:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 12:15:53 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> Message-ID: On 6/04/2020 11:50 am, David Holmes wrote: > There is something not right here ... > > On 4/04/2020 3:13 pm, Henry Jen wrote: >> Internal test shows that inline implementation is not working for some >> Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently >> defined, so it is actually broken. :) >> >>> [2020-04-03T15:59:26,981Z] Creating >>> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) > > Are you sure that line actually pertains to any error? The test defines > a custom launcher which doesn't use libjli so should never be including > the header file we are discussing. > >>> [2020-04-03T16:02:10,984Z] >>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default >>> (product-bundles test-bundles static-libs-bundles)' in configuration >>> 'solaris-sparcv9-open' (exit code 2) >>> [2020-04-03T16:02:11,051Z] >>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) >>> repeated here === >>> [2020-04-03T16:02:11,055Z] * For target >>> support_native_java.base_libjli_BUILD_LIBJLI_link: >>> [2020-04-03T16:02:11,061Z] Undefined??????????? first referenced >>> [2020-04-03T16:02:11,061Z]? symbol????????????????? in file >>> [2020-04-03T16:02:11,061Z] getTimeMicros >>> /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>> >>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors > > This looks like a direct linkage error. AFAICS > ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher > executables. But if we are building libjli it is not an executable. I'm > suspecting there is actually a long standing build bug here from when > libjli was introduced. Possibly only evident on an incremental build. I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. David > David > ----- > >>> [2020-04-03T16:02:11,082Z] >>> [2020-04-03T16:02:11,082Z] * All command lines available in >>> /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>> >>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>> [2020-04-03T16:02:11,094Z] >>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target >>> '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' >>> failed >>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target >>> 'java.base-libs' failed >>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>> [2020-04-03T16:02:11,741Z] >> >> >> I verified that either move implementation into .c as a function >> body[1] or change to #ifdef __solaris__[2] will fix that. So I think >> we will change to detect __solaris__ as webrev[2] rather than have an >> extra #define. If some other build want to have that, they can be >> modify that #ifdef easily. >> >> As I look into it, I found Mac have similar implementation with minor >> mistake, so I fixed that as well. Please review following based on >> zhanglin?s patch. >> >> I?ll push [2] once I got a +1. >> >> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >> >> Cheers, >> Henry >> >>> On Apr 2, 2020, at 6:17 AM, Alan Bateman >>> wrote: >>> >>> On 02/04/2020 11:26, linzang(??) wrote: >>>> : >>>> ??????????? Here is the updated webrev : >>>> http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>> ??????????? Thanks for your help! >>>> >>> webrev04 looks good. My preference was to was to replace #ifdef >>> HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be >>> appetite to do this now. I think Henry has offered to help sponsor. >>> >>> -Alan. >> From henry.jen at oracle.com Mon Apr 6 02:20:32 2020 From: henry.jen at oracle.com (Henry Jen) Date: Sun, 5 Apr 2020 19:20:32 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> Message-ID: <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> On Apr 5, 2020, at 7:15 PM, David Holmes wrote: > > On 6/04/2020 11:50 am, David Holmes wrote: >> There is something not right here ... >> On 4/04/2020 3:13 pm, Henry Jen wrote: >>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >>> >>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >> Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >>>> [2020-04-03T16:02:10,984Z] >>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >>>> [2020-04-03T16:02:11,051Z] >>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >>>> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >>>> [2020-04-03T16:02:11,061Z] Undefined first referenced >>>> [2020-04-03T16:02:11,061Z] symbol in file >>>> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >> This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. > > I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. > I should say it?s the inconsistency for building java.c for launcher executable and libjli.so, thus cause libjli.so failed to build. It wasn?t detected before because CounterGet is defined as no-op, so nothing to link with. Cheers, Henry > David > >> David >> ----- >>>> [2020-04-03T16:02:11,082Z] >>>> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>> [2020-04-03T16:02:11,094Z] >>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>> [2020-04-03T16:02:11,741Z] >>> >>> >>> I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. >>> >>> As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. >>> >>> I?ll push [2] once I got a +1. >>> >>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>> >>> Cheers, >>> Henry >>> >>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >>>> >>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>> : >>>>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>> Thanks for your help! >>>>> >>>> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >>>> >>>> -Alan. From david.holmes at oracle.com Mon Apr 6 02:37:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 12:37:41 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> Message-ID: <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> On 6/04/2020 12:20 pm, Henry Jen wrote: > On Apr 5, 2020, at 7:15 PM, David Holmes wrote: >> >> On 6/04/2020 11:50 am, David Holmes wrote: >>> There is something not right here ... >>> On 4/04/2020 3:13 pm, Henry Jen wrote: >>>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >>>> >>>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >>> Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >>>>> [2020-04-03T16:02:10,984Z] >>>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >>>>> [2020-04-03T16:02:11,051Z] >>>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >>>>> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >>>>> [2020-04-03T16:02:11,061Z] Undefined first referenced >>>>> [2020-04-03T16:02:11,061Z] symbol in file >>>>> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >>> This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. >> >> I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. >> > > I should say it?s the inconsistency for building java.c for launcher executable and libjli.so, thus cause libjli.so failed to build. It wasn?t detected before because CounterGet is defined as no-op, so nothing to link with. My point is that this seems completely broken. HAVE_GETHRTIME is never defined when building libjli, only when building the launcher executables, and the launcher executable code never calls CounterGet(). This suggests that the launcher debug code on Solaris has been using the same code as linux and thus should be seen to be reporting the same thing ... which it is ... _JAVA_LAUNCHER_DEBUG=true /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java -version ----_JAVA_LAUNCHER_DEBUG---- Launcher state: First application arg index: -1 debug:on javargs:off program name:java launcher name:java javaw:off fullversion:9+181 Command line args: argv[0] = /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java argv[1] = -version JRE path is .../java_re/jdk/9/fcs/181/binaries/solaris-x64 jvm.cfg[0] = ->-server<- jvm.cfg[1] = ->-client<- 1 micro seconds to parse jvm.cfg Default VM: server Does `.../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so' exist ... yes. mustsetenv: FALSE JVM path is .../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so 1 micro seconds to LoadJavaVM Always reports 1 microsecond just like Linux. This whole setup is completely broken at the build level. Cheers, David > Cheers, > Henry > > >> David >> >>> David >>> ----- >>>>> [2020-04-03T16:02:11,082Z] >>>>> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>>> [2020-04-03T16:02:11,094Z] >>>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >>>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >>>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>>> [2020-04-03T16:02:11,741Z] >>>> >>>> >>>> I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. >>>> >>>> As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. >>>> >>>> I?ll push [2] once I got a +1. >>>> >>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>>> >>>> Cheers, >>>> Henry >>>> >>>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >>>>> >>>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>>> : >>>>>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>>> Thanks for your help! >>>>>> >>>>> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >>>>> >>>>> -Alan. > From david.holmes at oracle.com Mon Apr 6 04:21:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Apr 2020 14:21:26 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> Message-ID: <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> On 6/04/2020 12:37 pm, David Holmes wrote: > On 6/04/2020 12:20 pm, Henry Jen wrote: >> On Apr 5, 2020, at 7:15 PM, David Holmes wrote: >>> >>> On 6/04/2020 11:50 am, David Holmes wrote: >>>> There is something not right here ... >>>> On 4/04/2020 3:13 pm, Henry Jen wrote: >>>>> Internal test shows that inline implementation is not working for >>>>> some Solaris artifacts, because the -DHAVE_GETHRTIME is not >>>>> consistently defined, so it is actually broken. :) >>>>> >>>>>> [2020-04-03T15:59:26,981Z] Creating >>>>>> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 >>>>>> file(s) >>>> Are you sure that line actually pertains to any error? The test >>>> defines a custom launcher which doesn't use libjli so should never >>>> be including the header file we are discussing. >>>>>> [2020-04-03T16:02:10,984Z] >>>>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default >>>>>> (product-bundles test-bundles static-libs-bundles)' in >>>>>> configuration 'solaris-sparcv9-open' (exit code 2) >>>>>> [2020-04-03T16:02:11,051Z] >>>>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) >>>>>> repeated here === >>>>>> [2020-04-03T16:02:11,055Z] * For target >>>>>> support_native_java.base_libjli_BUILD_LIBJLI_link: >>>>>> [2020-04-03T16:02:11,061Z] Undefined??????????? first referenced >>>>>> [2020-04-03T16:02:11,061Z]? symbol????????????????? in file >>>>>> [2020-04-03T16:02:11,061Z] getTimeMicros >>>>>> /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>>>> >>>>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >>>> This looks like a direct linkage error. AFAICS >>>> ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for >>>> launcher executables. But if we are building libjli it is not an >>>> executable. I'm suspecting there is actually a long standing build >>>> bug here from when libjli was introduced. Possibly only evident on >>>> an incremental build. >>> >>> I can confirm that the flags set in LauncherCommon.gmk are not passed >>> to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to >>> the linux flags and checked the build). So I have no idea how this >>> has been working, if indeed it actually has. >>> >> >> I should say it?s the inconsistency for building java.c for launcher >> executable and libjli.so, thus cause libjli.so failed to build. It >> wasn?t detected before because CounterGet is defined as no-op, so >> nothing to link with. > > My point is that this seems completely broken. HAVE_GETHRTIME is never > defined when building libjli, only when building the launcher > executables, and the launcher executable code never calls CounterGet(). > This suggests that the launcher debug code on Solaris has been using the > same code as linux and thus should be seen to be reporting the same > thing ... which it is ... > > _JAVA_LAUNCHER_DEBUG=true > /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java -version > ----_JAVA_LAUNCHER_DEBUG---- > Launcher state: > ??????? First application arg index: -1 > ??????? debug:on > ??????? javargs:off > ??????? program name:java > ??????? launcher name:java > ??????? javaw:off > ??????? fullversion:9+181 > Command line args: > argv[0] = /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java > argv[1] = -version > JRE path is .../java_re/jdk/9/fcs/181/binaries/solaris-x64 > jvm.cfg[0] = ->-server<- > jvm.cfg[1] = ->-client<- > 1 micro seconds to parse jvm.cfg > Default VM: server > Does > `.../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so' > exist ... yes. > mustsetenv: FALSE > JVM path is > .../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so > 1 micro seconds to LoadJavaVM > > Always reports 1 microsecond just like Linux. > > This whole setup is completely broken at the build level. This worked correctly in JDK 6 (6u181 is latest I could test) but is broken in JDK 7. David ----- > > Cheers, > David > >> Cheers, >> Henry >> >> >>> David >>> >>>> David >>>> ----- >>>>>> [2020-04-03T16:02:11,082Z] >>>>>> [2020-04-03T16:02:11,082Z] * All command lines available in >>>>>> /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>>>> >>>>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>>>> [2020-04-03T16:02:11,094Z] >>>>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for >>>>>> target >>>>>> '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' >>>>>> failed >>>>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target >>>>>> 'java.base-libs' failed >>>>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>>>> [2020-04-03T16:02:11,741Z] >>>>> >>>>> >>>>> I verified that either move implementation into .c as a function >>>>> body[1] or change to #ifdef __solaris__[2] will fix that. So I >>>>> think we will change to detect __solaris__ as webrev[2] rather than >>>>> have an extra #define. If some other build want to have that, they >>>>> can be modify that #ifdef easily. >>>>> >>>>> As I look into it, I found Mac have similar implementation with >>>>> minor mistake, so I fixed that as well. Please review following >>>>> based on zhanglin?s patch. >>>>> >>>>> I?ll push [2] once I got a +1. >>>>> >>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>>>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman >>>>>> wrote: >>>>>> >>>>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>>>> : >>>>>>> ???????????? Here is the updated webrev : >>>>>>> http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>>>> ???????????? Thanks for your help! >>>>>>> >>>>>> webrev04 looks good. My preference was to was to replace #ifdef >>>>>> HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to >>>>>> be appetite to do this now. I think Henry has offered to help >>>>>> sponsor. >>>>>> >>>>>> -Alan. >> From powers.anirvan at gmail.com Mon Apr 6 05:24:44 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Mon, 6 Apr 2020 14:24:44 +0900 Subject: [PATCH] Trivial improvement for j.l.Character.toString() - 8241649: Optimize Character.toString In-Reply-To: <46a3b334-0dcd-6d11-53b4-f0a9f7dd68eb@oracle.com> References: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> <4ff0c485-8e6e-af22-59af-c50be5824a19@oracle.com> <46a3b334-0dcd-6d11-53b4-f0a9f7dd68eb@oracle.com> Message-ID: JDK-8189375 should be closed as duplicate. On Thu, 26 Mar 2020 at 18:06, Claes Redestad wrote: > Filed and pushed: https://bugs.openjdk.java.net/browse/JDK-8241649 > > /Claes > > On 2020-03-26 00:12, Roger Riggs wrote: > > Agreed, +1 > > > > On 3/25/20 5:53 PM, Claes Redestad wrote: > >> Looks good and trivial, including the drive-by cleanups. > >> > >> I can sponsor. > >> > >> /Claes > >> > >> On 2020-03-25 22:18, ?????? ??????? wrote: > >>> Hello, > >>> > >>> I think we can reduce allocation rate for j.l.Character.toString() by > >>> calling String.valueOf(char) instead of String.valueOf(char[]). > >>> > >>> Current implementation creates char[] with one char which is later > >>> decoded into byte[]. > >>> > >>> Instead String.valueOf(char) decodes char directly consuming less > >>> memory. I've used benchmark [1] > >>> and on my machine got those results (JDK 14): > >>> > >>> Benchmark Mode Score Error Units > >>> > >>> CharacterToStringBenchmark.toString_utf8 avgt 14.723 ? 1.354 > ns/op > >>> CharacterToStringBenchmark.valueOf_utf8 avgt 7.678 ? 0.601 ns/op > >>> > >>> CharacterToStringBenchmark.toString_latin avgt 10.992 ? 1.371 ns/op > >>> CharacterToStringBenchmark.valueOf_latin avgt 7.844 ? 1.044 > ns/op > >>> > >>> CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt > >>> 96.003 ? 0.001 B/op > >>> CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt > >>> 48.002 ? 0.001 B/op > >>> > >>> CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt > >>> 72.003 ? 0.001 B/op > >>> CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt > >>> 48.002 ? 0.001 B/op > >>> > >>> > >>> Patch is below. > >>> > >>> With best regards, > >>> Sergey Tsypanov > >>> > >>> [1] > >>> > https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java > >>> > >>> > >>> diff --git a/src/java.base/share/classes/java/lang/Character.java > >>> b/src/java.base/share/classes/java/lang/Character.java > >>> --- a/src/java.base/share/classes/java/lang/Character.java > >>> +++ b/src/java.base/share/classes/java/lang/Character.java > >>> @@ -3285,7 +3285,7 @@ > >>> "SYMBOLS AND PICTOGRAPHS EXTENDED-A", > >>> "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); > >>> - private static final int blockStarts[] = { > >>> + private static final int[] blockStarts = { > >>> 0x0000, // 0000..007F; Basic Latin > >>> 0x0080, // 0080..00FF; Latin-1 Supplement > >>> 0x0100, // 0100..017F; Latin Extended-A > >>> @@ -8068,7 +8068,7 @@ > >>> UNKNOWN, // E01F0..10FFFF > >>> }; > >>> - private static HashMap > >>> aliases; > >>> + private static final HashMap >>> Character.UnicodeScript> aliases; > >>> static { > >>> aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); > >>> aliases.put("ADLM", ADLAM); > >>> @@ -8421,8 +8421,7 @@ > >>> * @return a string representation of this object. > >>> */ > >>> public String toString() { > >>> - char buf[] = {value}; > >>> - return String.valueOf(buf); > >>> + return toString(value); > >>> } > >>> /** > >>> > > > -- Anirvan From claes.redestad at oracle.com Mon Apr 6 10:10:50 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 12:10:50 +0200 Subject: [PATCH] Trivial improvement for j.l.Character.toString() - 8241649: Optimize Character.toString In-Reply-To: References: <10130881585167129@vla3-6a5326aeb4ee.qloud-c.yandex.net> <77c281a8-6cd5-df79-f2f0-0f399741d116@oracle.com> <4ff0c485-8e6e-af22-59af-c50be5824a19@oracle.com> <46a3b334-0dcd-6d11-53b4-f0a9f7dd68eb@oracle.com> Message-ID: Good catch. Closed it as duplicate - also surprised myself that I didn't find this one when I did a cursory search in JBS for pre-existing issues. /Claes On 2020-04-06 07:24, Anirvan Sarkar wrote: > JDK-8189375 should be > closed as duplicate. > > On Thu, 26 Mar 2020 at 18:06, Claes Redestad > wrote: > > Filed and pushed: https://bugs.openjdk.java.net/browse/JDK-8241649 > > /Claes > > On 2020-03-26 00:12, Roger Riggs wrote: > > Agreed,? +1 > > > > On 3/25/20 5:53 PM, Claes Redestad wrote: > >> Looks good and trivial, including the drive-by cleanups. > >> > >> I can sponsor. > >> > >> /Claes > >> > >> On 2020-03-25 22:18, ?????? ??????? wrote: > >>> Hello, > >>> > >>> I think we can reduce allocation rate for > j.l.Character.toString() by > >>> calling String.valueOf(char) instead of String.valueOf(char[]). > >>> > >>> Current implementation creates char[] with one char which is later > >>> decoded into byte[]. > >>> > >>> Instead String.valueOf(char) decodes char directly consuming less > >>> memory. I've used benchmark [1] > >>> and on my machine got those results (JDK 14): > >>> > >>> Benchmark Mode??? Score???? Error?? Units > >>> > >>> CharacterToStringBenchmark.toString_utf8 avgt?? 14.723 ? > 1.354?? ns/op > >>> CharacterToStringBenchmark.valueOf_utf8 avgt??? 7.678 ? > 0.601?? ns/op > >>> > >>> CharacterToStringBenchmark.toString_latin avgt?? 10.992 ? > 1.371 ns/op > >>> CharacterToStringBenchmark.valueOf_latin avgt??? 7.844 ? > 1.044?? ns/op > >>> > >>> CharacterToStringBenchmark.toString_utf8:?gc.alloc.rate.norm avgt > >>> 96.003 ??? 0.001??? B/op > >>> CharacterToStringBenchmark.valueOf_utf8:?gc.alloc.rate.norm avgt > >>> 48.002 ??? 0.001??? B/op > >>> > >>> CharacterToStringBenchmark.toString_latin:?gc.alloc.rate.norm avgt > >>> 72.003 ??? 0.001??? B/op > >>> CharacterToStringBenchmark.valueOf_latin:?gc.alloc.rate.norm avgt > >>> 48.002 ??? 0.001??? B/op > >>> > >>> > >>> Patch is below. > >>> > >>> With best regards, > >>> Sergey Tsypanov > >>> > >>> [1] > >>> > https://github.com/stsypanov/strings/blob/master/src/jmh/java/tsypanov/strings/character/CharacterToStringBenchmark.java > > >>> > >>> > >>> diff --git a/src/java.base/share/classes/java/lang/Character.java > >>> b/src/java.base/share/classes/java/lang/Character.java > >>> --- a/src/java.base/share/classes/java/lang/Character.java > >>> +++ b/src/java.base/share/classes/java/lang/Character.java > >>> @@ -3285,7 +3285,7 @@ > >>> ?????????????????????????????? "SYMBOLS AND PICTOGRAPHS > EXTENDED-A", > >>> "SYMBOLSANDPICTOGRAPHSEXTENDED-A"); > >>> ? -??????? private static final int blockStarts[] = { > >>> +??????? private static final int[] blockStarts = { > >>> ????????????? 0x0000,?? // 0000..007F; Basic Latin > >>> ????????????? 0x0080,?? // 0080..00FF; Latin-1 Supplement > >>> ????????????? 0x0100,?? // 0100..017F; Latin Extended-A > >>> @@ -8068,7 +8068,7 @@ > >>> ????????????? UNKNOWN,????????????????? // E01F0..10FFFF > >>> ????????? }; > >>> ? -??????? private static HashMap > >>> aliases; > >>> +??????? private static final HashMap >>> Character.UnicodeScript> aliases; > >>> ????????? static { > >>> ????????????? aliases = new HashMap<>((int)(153 / 0.75f + 1.0f)); > >>> ????????????? aliases.put("ADLM", ADLAM); > >>> @@ -8421,8 +8421,7 @@ > >>> ?????? * @return? a string representation of this object. > >>> ?????? */ > >>> ????? public String toString() { > >>> -??????? char buf[] = {value}; > >>> -??????? return String.valueOf(buf); > >>> +??????? return toString(value); > >>> ????? } > >>> ? ????? /** > >>> > > > > > > -- > Anirvan From claes.redestad at oracle.com Mon Apr 6 10:29:02 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 12:29:02 +0200 Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL) In-Reply-To: References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> Message-ID: <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com> Hi, (including net-dev at .. since this is in java.net) I intend to sponsor this trivial patch provided by Christoph: diff -r 65b345254ca3 src/java.base/share/classes/java/net/URLStreamHandler.java --- a/src/java.base/share/classes/java/net/URLStreamHandler.java Thu Apr 02 05:44:04 2020 +0000 +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java Mon Apr 06 12:27:09 2020 +0200 @@ -266,8 +266,8 @@ spec.substring(start, limit); } else { - String separator = (authority != null) ? "/" : ""; - path = separator + spec.substring(start, limit); + path = spec.substring(start, limit); + path = (authority != null) ? "/" + path : path; } } else if (queryOnly && path != null) { int ind = path.lastIndexOf('/'); Bug: https://bugs.openjdk.java.net/browse/JDK-8242186 Let me know if there are any concerns, otherwise I'll push once tier1 testing comes back green. Thanks! /Claes On 2020-04-05 19:48, Claes Redestad wrote: > Hi Christoph, > > looks good and trivial. I'll sponsor. > > /Claes > > On 2020-04-05 10:57, Christoph Dreis wrote: >> Hi, >> >> I just noticed a small optimization opportunity in >> URLStreamHandler.parseURL for inputs like the following: >> >> ????new URL(new URL("file:"), "file:./path/to/some/local.properties"); >> >> In those cases there is no authority involved, which makes it possible >> to rewrite URLStreamHandler:L269-270: >> ???? String separator = (authority != null) ? "/" : ""; >> ???? path = separator + spec.substring(start, limit); >> >> into the following to avoid unnecessary string concatenations with an >> empty string: >> >> ????? path = spec.substring(start, limit); >> ????? path = (authority != null) ? "/" + path : path; >> >> I've written a small benchmark with two URLStreamHandler variants (one >> with the old parseURL and one with the new): >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class MyBenchmark { >> >> ???? @State(Scope.Benchmark) >> ???? public static class ThreadState { >> >> ???????? private URL context; >> ???????? private URLStreamHandler newHandler = new NewURLStreamHandler(); >> ???????? private URLStreamHandler oldHandler = new OldURLStreamHandler(); >> ???????? private String spec = >> "file:./path/to/some/application.properties"; >> >> ???????? public ThreadState() { >> ???????????? try { >> ???????????????? context = new URL("file:"); >> ???????????? } catch (MalformedURLException ignored) { >> >> ???????????? } >> ???????? } >> ???? } >> >> ???? @Benchmark >> ???? public URL testNew(ThreadState threadState) throws >> MalformedURLException { >> ???????? return new URL(threadState.context, threadState.spec, >> threadState.newHandler); >> ???? } >> >> ???? @Benchmark >> ???? public URL testOld(ThreadState threadState) throws >> MalformedURLException { >> ???????? return new URL(threadState.context, threadState.spec, >> threadState.oldHandler); >> ???? } >> >> } >> >> The benchmark above yields the following results on my local machine: >> >> Benchmark???????????????????????????????????????????? Mode? Cnt >> Score??? Error?? Units >> MyBenchmark.testNew?????????????????????????????????? avgt?? 10 >> 112,655 ?? 3,494?? ns/op >> MyBenchmark.testNew:?gc.alloc.rate??????????????????? avgt?? 10 >> 1299,558 ? 41,238? MB/sec >> MyBenchmark.testNew:?gc.alloc.rate.norm?????????????? avgt?? 10 >> 192,015 ?? 0,003??? B/op >> MyBenchmark.testNew:?gc.count???????????????????????? avgt?? 10 >> 98,000?????????? counts >> MyBenchmark.testNew:?gc.time????????????????????????? avgt?? 10 >> 105,000?????????????? ms >> MyBenchmark.testOld?????????????????????????????????? avgt?? 10 >> 128,592 ?? 1,183?? ns/op >> MyBenchmark.testOld:?gc.alloc.rate??????????????????? avgt?? 10 >> 1612,743 ? 15,792? MB/sec >> MyBenchmark.testOld:?gc.alloc.rate.norm?????????????? avgt?? 10 >> 272,019 ?? 0,001??? B/op >> MyBenchmark.testOld:?gc.count???????????????????????? avgt?? 10 >> 110,000?????????? counts >> MyBenchmark.testOld:?gc.time????????????????????????? avgt?? 10 >> 121,000?????????????? ms >> >> >> In case you think this is worthwhile I would need someone to sponsor >> the attached patch for me. >> I would highly appreciate that. >> >> Cheers, >> Christoph >> >> >> ===== PATCH ===== >> diff --git >> a/src/java.base/share/classes/java/net/URLStreamHandler.java >> b/src/java.base/share/classes/java/net/URLStreamHandler.java >> --- a/src/java.base/share/classes/java/net/URLStreamHandler.java >> +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java >> @@ -266,8 +266,8 @@ >> ?????????????????????????? spec.substring(start, limit); >> >> ????????????? } else { >> -??????????????? String separator = (authority != null) ? "/" : ""; >> -??????????????? path = separator + spec.substring(start, limit); >> +??????????????? path = spec.substring(start, limit); >> +??????????????? path = (authority != null) ? "/" + path : path; >> ????????????? } >> ????????? } else if (queryOnly && path != null) { >> ????????????? int ind = path.lastIndexOf('/'); >> >> From claes.redestad at oracle.com Mon Apr 6 10:44:10 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 12:44:10 +0200 Subject: Use Method.getParameterCount() where possible In-Reply-To: <9865F20E-0B64-4C78-9819-14579D7C0FE7@freenet.de> References: <9865F20E-0B64-4C78-9819-14579D7C0FE7@freenet.de> Message-ID: <2a978197-c634-d739-43d7-580a94ecddee@oracle.com> Hi, looks good and trivial to me. I'll sponsor. /Claes (I hope we can wrap up https://bugs.openjdk.java.net/browse/JDK-8029019 some day, soon) On 2020-04-03 12:19, Christoph Dreis wrote: > Hi, > > I noticed that the JDK itself still uses Method.getParameterTypes().length in a couple of places. > > This could be replaced with Method.getParameterCount() to avoid unnecessary cloning overhead. > While this is often optimized away, I guess it's still good to not rely on that. Additionally, it's a little more concise to read. > > If you think this is worthwhile, I would need someone to sponsor that tiny change. > > P.S.: There is another occurrence in ForkJoinTask where I wasn't sure if I should change that, because it's usually changed under the JSR166 umbrella afaik. > > Cheers, > Christoph > > ==== PATCH ==== > > diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java > @@ -276,13 +276,13 @@ > switch (m.getName()) { > case "toString": > return (m.getReturnType() == String.class > - && m.getParameterTypes().length == 0); > + && m.getParameterCount() == 0); > case "hashCode": > return (m.getReturnType() == int.class > - && m.getParameterTypes().length == 0); > + && m.getParameterCount() == 0); > case "equals": > return (m.getReturnType() == boolean.class > - && m.getParameterTypes().length == 1 > + && m.getParameterCount() == 1 > && m.getParameterTypes()[0] == Object.class); > } > return false; > diff --git a/src/java.base/share/classes/java/lang/reflect/Executable.java b/src/java.base/share/classes/java/lang/reflect/Executable.java > --- a/src/java.base/share/classes/java/lang/reflect/Executable.java > +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java > @@ -378,7 +378,7 @@ > private void verifyParameters(final Parameter[] parameters) { > final int mask = Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; > > - if (getParameterTypes().length != parameters.length) > + if (getParameterCount() != parameters.length) > throw new MalformedParametersException("Wrong number of parameters in MethodParameters attribute"); > > for (Parameter parameter : parameters) { > diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java > --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java > +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java > @@ -121,7 +121,7 @@ > if (Modifier.isPublic(method.getModifiers()) && > Modifier.isAbstract(method.getModifiers()) && > !method.isSynthetic()) { > - if (method.getParameterTypes().length != 0) { > + if (method.getParameterCount() != 0) { > throw new IllegalArgumentException(method + " has params"); > } > String name = method.getName(); > > From chris.hegarty at oracle.com Mon Apr 6 11:22:03 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Apr 2020 12:22:03 +0100 Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL) In-Reply-To: <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com> References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com> Message-ID: > On 6 Apr 2020, at 11:29, Claes Redestad wrote: > > Hi, > > (including net-dev at .. since this is in java.net) > > I intend to sponsor this trivial patch provided by Christoph: > > diff -r 65b345254ca3 src/java.base/share/classes/java/net/URLStreamHandler.java > --- a/src/java.base/share/classes/java/net/URLStreamHandler.java Thu Apr 02 05:44:04 2020 +0000 > +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java Mon Apr 06 12:27:09 2020 +0200 > @@ -266,8 +266,8 @@ > spec.substring(start, limit); > > } else { > - String separator = (authority != null) ? "/" : ""; > - path = separator + spec.substring(start, limit); > + path = spec.substring(start, limit); > + path = (authority != null) ? "/" + path : path; > } > } else if (queryOnly && path != null) { > int ind = path.lastIndexOf('/'); > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242186 > > Let me know if there are any concerns, otherwise I'll push > once tier1 testing comes back green. Thanks! Thanks all for this nice micro-optimization. The changes look good to me. -Chris. > /Claes > > On 2020-04-05 19:48, Claes Redestad wrote: >> Hi Christoph, >> looks good and trivial. I'll sponsor. >> /Claes >> On 2020-04-05 10:57, Christoph Dreis wrote: >>> Hi, >>> >>> I just noticed a small optimization opportunity in URLStreamHandler.parseURL for inputs like the following: >>> >>> new URL(new URL("file:"), "file:./path/to/some/local.properties"); >>> >>> In those cases there is no authority involved, which makes it possible to rewrite URLStreamHandler:L269-270: >>> String separator = (authority != null) ? "/" : ""; >>> path = separator + spec.substring(start, limit); >>> >>> into the following to avoid unnecessary string concatenations with an empty string: >>> >>> path = spec.substring(start, limit); >>> path = (authority != null) ? "/" + path : path; >>> >>> I've written a small benchmark with two URLStreamHandler variants (one with the old parseURL and one with the new): >>> >>> @BenchmarkMode(Mode.AverageTime) >>> @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> public class MyBenchmark { >>> >>> @State(Scope.Benchmark) >>> public static class ThreadState { >>> >>> private URL context; >>> private URLStreamHandler newHandler = new NewURLStreamHandler(); >>> private URLStreamHandler oldHandler = new OldURLStreamHandler(); >>> private String spec = "file:./path/to/some/application.properties"; >>> >>> public ThreadState() { >>> try { >>> context = new URL("file:"); >>> } catch (MalformedURLException ignored) { >>> >>> } >>> } >>> } >>> >>> @Benchmark >>> public URL testNew(ThreadState threadState) throws MalformedURLException { >>> return new URL(threadState.context, threadState.spec, threadState.newHandler); >>> } >>> >>> @Benchmark >>> public URL testOld(ThreadState threadState) throws MalformedURLException { >>> return new URL(threadState.context, threadState.spec, threadState.oldHandler); >>> } >>> >>> } >>> >>> The benchmark above yields the following results on my local machine: >>> >>> Benchmark Mode Cnt Score Error Units >>> MyBenchmark.testNew avgt 10 112,655 ? 3,494 ns/op >>> MyBenchmark.testNew:?gc.alloc.rate avgt 10 1299,558 ? 41,238 MB/sec >>> MyBenchmark.testNew:?gc.alloc.rate.norm avgt 10 192,015 ? 0,003 B/op >>> MyBenchmark.testNew:?gc.count avgt 10 98,000 counts >>> MyBenchmark.testNew:?gc.time avgt 10 105,000 ms >>> MyBenchmark.testOld avgt 10 128,592 ? 1,183 ns/op >>> MyBenchmark.testOld:?gc.alloc.rate avgt 10 1612,743 ? 15,792 MB/sec >>> MyBenchmark.testOld:?gc.alloc.rate.norm avgt 10 272,019 ? 0,001 B/op >>> MyBenchmark.testOld:?gc.count avgt 10 110,000 counts >>> MyBenchmark.testOld:?gc.time avgt 10 121,000 ms >>> >>> >>> In case you think this is worthwhile I would need someone to sponsor the attached patch for me. >>> I would highly appreciate that. >>> >>> Cheers, >>> Christoph >>> >>> >>> ===== PATCH ===== >>> diff --git a/src/java.base/share/classes/java/net/URLStreamHandler.java b/src/java.base/share/classes/java/net/URLStreamHandler.java >>> --- a/src/java.base/share/classes/java/net/URLStreamHandler.java >>> +++ b/src/java.base/share/classes/java/net/URLStreamHandler.java >>> @@ -266,8 +266,8 @@ >>> spec.substring(start, limit); >>> >>> } else { >>> - String separator = (authority != null) ? "/" : ""; >>> - path = separator + spec.substring(start, limit); >>> + path = spec.substring(start, limit); >>> + path = (authority != null) ? "/" + path : path; >>> } >>> } else if (queryOnly && path != null) { >>> int ind = path.lastIndexOf('/'); >>> >>> From claes.redestad at oracle.com Mon Apr 6 11:26:49 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 13:26:49 +0200 Subject: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL) In-Reply-To: References: <3D3B30BF-B10E-499E-AA30-E186D221A27B@freenet.de> <4fecfe4c-1f30-5d11-cc4e-a2b8d118a1d3@oracle.com> Message-ID: <554bffd1-f023-6f79-3550-e8694fd3f9fd@oracle.com> On 2020-04-06 13:22, Chris Hegarty wrote: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8242186 >> >> Let me know if there are any concerns, otherwise I'll push >> once tier1 testing comes back green. Thanks! > Thanks all for this nice micro-optimization. The changes look good to me. > > -Chris. > Thanks, Chris! /Claes From chris.hegarty at oracle.com Mon Apr 6 11:38:51 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Apr 2020 12:38:51 +0100 Subject: Use Method.getParameterCount() where possible In-Reply-To: <2a978197-c634-d739-43d7-580a94ecddee@oracle.com> References: <9865F20E-0B64-4C78-9819-14579D7C0FE7@freenet.de> <2a978197-c634-d739-43d7-580a94ecddee@oracle.com> Message-ID: The changes look good to me. -Chris. > On 6 Apr 2020, at 11:44, Claes Redestad wrote: > > Hi, > > looks good and trivial to me. I'll sponsor. > > /Claes > > (I hope we can wrap up https://bugs.openjdk.java.net/browse/JDK-8029019 > some day, soon) > > On 2020-04-03 12:19, Christoph Dreis wrote: >> Hi, >> I noticed that the JDK itself still uses Method.getParameterTypes().length in a couple of places. >> This could be replaced with Method.getParameterCount() to avoid unnecessary cloning overhead. >> While this is often optimized away, I guess it's still good to not rely on that. Additionally, it's a little more concise to read. >> If you think this is worthwhile, I would need someone to sponsor that tiny change. >> P.S.: There is another occurrence in ForkJoinTask where I wasn't sure if I should change that, because it's usually changed under the JSR166 umbrella afaik. >> Cheers, >> Christoph >> ==== PATCH ==== >> diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >> @@ -276,13 +276,13 @@ >> switch (m.getName()) { >> case "toString": >> return (m.getReturnType() == String.class >> - && m.getParameterTypes().length == 0); >> + && m.getParameterCount() == 0); >> case "hashCode": >> return (m.getReturnType() == int.class >> - && m.getParameterTypes().length == 0); >> + && m.getParameterCount() == 0); >> case "equals": >> return (m.getReturnType() == boolean.class >> - && m.getParameterTypes().length == 1 >> + && m.getParameterCount() == 1 >> && m.getParameterTypes()[0] == Object.class); >> } >> return false; >> diff --git a/src/java.base/share/classes/java/lang/reflect/Executable.java b/src/java.base/share/classes/java/lang/reflect/Executable.java >> --- a/src/java.base/share/classes/java/lang/reflect/Executable.java >> +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java >> @@ -378,7 +378,7 @@ >> private void verifyParameters(final Parameter[] parameters) { >> final int mask = Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; >> - if (getParameterTypes().length != parameters.length) >> + if (getParameterCount() != parameters.length) >> throw new MalformedParametersException("Wrong number of parameters in MethodParameters attribute"); >> for (Parameter parameter : parameters) { >> diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >> --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >> @@ -121,7 +121,7 @@ >> if (Modifier.isPublic(method.getModifiers()) && >> Modifier.isAbstract(method.getModifiers()) && >> !method.isSynthetic()) { >> - if (method.getParameterTypes().length != 0) { >> + if (method.getParameterCount() != 0) { >> throw new IllegalArgumentException(method + " has params"); >> } >> String name = method.getName(); From claes.redestad at oracle.com Mon Apr 6 11:49:24 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 13:49:24 +0200 Subject: Use Method.getParameterCount() where possible In-Reply-To: References: <9865F20E-0B64-4C78-9819-14579D7C0FE7@freenet.de> <2a978197-c634-d739-43d7-580a94ecddee@oracle.com> Message-ID: <7c98160d-3393-6f2f-3f50-e35a814d9a17@oracle.com> Thanks, pushed as https://bugs.openjdk.java.net/browse/JDK-8242208 /Claes On 2020-04-06 13:38, Chris Hegarty wrote: > The changes look good to me. > > -Chris. > >> On 6 Apr 2020, at 11:44, Claes Redestad wrote: >> >> Hi, >> >> looks good and trivial to me. I'll sponsor. >> >> /Claes >> >> (I hope we can wrap up https://bugs.openjdk.java.net/browse/JDK-8029019 >> some day, soon) >> >> On 2020-04-03 12:19, Christoph Dreis wrote: >>> Hi, >>> I noticed that the JDK itself still uses Method.getParameterTypes().length in a couple of places. >>> This could be replaced with Method.getParameterCount() to avoid unnecessary cloning overhead. >>> While this is often optimized away, I guess it's still good to not rely on that. Additionally, it's a little more concise to read. >>> If you think this is worthwhile, I would need someone to sponsor that tiny change. >>> P.S.: There is another occurrence in ForkJoinTask where I wasn't sure if I should change that, because it's usually changed under the JSR166 umbrella afaik. >>> Cheers, >>> Christoph >>> ==== PATCH ==== >>> diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >>> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >>> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java >>> @@ -276,13 +276,13 @@ >>> switch (m.getName()) { >>> case "toString": >>> return (m.getReturnType() == String.class >>> - && m.getParameterTypes().length == 0); >>> + && m.getParameterCount() == 0); >>> case "hashCode": >>> return (m.getReturnType() == int.class >>> - && m.getParameterTypes().length == 0); >>> + && m.getParameterCount() == 0); >>> case "equals": >>> return (m.getReturnType() == boolean.class >>> - && m.getParameterTypes().length == 1 >>> + && m.getParameterCount() == 1 >>> && m.getParameterTypes()[0] == Object.class); >>> } >>> return false; >>> diff --git a/src/java.base/share/classes/java/lang/reflect/Executable.java b/src/java.base/share/classes/java/lang/reflect/Executable.java >>> --- a/src/java.base/share/classes/java/lang/reflect/Executable.java >>> +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java >>> @@ -378,7 +378,7 @@ >>> private void verifyParameters(final Parameter[] parameters) { >>> final int mask = Modifier.FINAL | Modifier.SYNTHETIC | Modifier.MANDATED; >>> - if (getParameterTypes().length != parameters.length) >>> + if (getParameterCount() != parameters.length) >>> throw new MalformedParametersException("Wrong number of parameters in MethodParameters attribute"); >>> for (Parameter parameter : parameters) { >>> diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >>> --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >>> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java >>> @@ -121,7 +121,7 @@ >>> if (Modifier.isPublic(method.getModifiers()) && >>> Modifier.isAbstract(method.getModifiers()) && >>> !method.isSynthetic()) { >>> - if (method.getParameterTypes().length != 0) { >>> + if (method.getParameterCount() != 0) { >>> throw new IllegalArgumentException(method + " has params"); >>> } >>> String name = method.getName(); > From joel.borggren.franck at gmail.com Mon Apr 6 12:00:59 2020 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Mon, 6 Apr 2020 14:00:59 +0200 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References: <0aaaa441-c193-6155-4da3-5bd91888f73e@oracle.com> Message-ID: Many thanks to Vicente for sponsoring this. I'll start to look at the second part shortly. cheers /Joel On Mon, Mar 16, 2020 at 9:44 PM Joel Borggr?n-Franck < joel.borggren.franck at gmail.com> wrote: > Looks good to me! > > I'll see if I can find a sponsor for this. > > cheers > /Joel > > On Sat, Mar 7, 2020 at 2:15 AM Rafael Winterhalter > wrote: > >> I finally found the time to look at this again, sorry for the delay. >> >> Thank you for your comments. I had the chance to better look into the >> problem and simplify the code a bit more and also reduced the scope of the >> fix to a single problem. I also added test cases that should be exhaustive >> for all possible scenarios and adjusted the code comment. >> >> I uploaded the adjusted patch as a webrev: >> http://cr.openjdk.java.net/~winterhalter/8202469/webrev.01/ >> >> Thanks, Rafael >> >> Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggr?n-Franck < >> joel.borggren.franck at gmail.com>: >> >>> Hi Rafael, >>> >>> Thanks for reaching out and reminding me of this! >>> >>> I managed to find some time to look into 8202469 during the weekend. By >>> swapping place of the TVars in the test I managed to isolate this without >>> depending on 8202473, take a look at my hacky copy-paste update to your >>> test at http://cr.openjdk.java.net/~jfranck/8202469/ . >>> >>> The comment on lines 269-276 needs to be updated. Perhaps include a >>> table with the start index depending of the type? Also referencing JVMLS >>> 4.4 for the structure of the bound might be instructive for future readers. >>> >>> My current understanding is that there are two problems with the code on >>> (the original) lines 277-287: >>> 1) Type Variables should have index 0 while getting index 1 due to lines >>> 279-280. >>> 2) Bounds that are instances of ParameterizedType always gets index 1 >>> but if the first bound represents a Class type the index should be 0. >>> >>> Does this make sense? >>> >>> Can you make the if-switches positive? I find my original code with the >>> negative tests hard to read and the update doesn't help. >>> >>> Also can you expand the test to cover the different kinds of bounds >>> mentioned in 4.4 and also test Type Variables on methods, I suspect javac >>> treats method (and constructor) tvars similarly but there have been bugs ... >>> >>> TL;DR please update the webrev with: >>> >>> - Split out test and fix for 8202469 >>> - More test coverage of different kinds of bounds >>> - Test for method tvars >>> - See if you can rework the logic to have (mostly) positive tests in if >>> switch >>> >>> Thanks again for looking into this, I'll start looking into 8202473, I >>> think the fix for that one opens up a bigger rework of the code which is >>> why I want to separate the two. >>> >>> cheers >>> /Joel >>> >>> On Sun, Aug 4, 2019 at 10:12 PM Rafael Winterhalter < >>> rafael.wth at gmail.com> wrote: >>> >>>> Hi, >>>> >>>> appologies for the delay, I only managed to get my patched up to webrev >>>> today (http://cr.openjdk.java.net/~winterhalter/). It's three patches >>>> in total now, for the third one I could not add a test case, it would >>>> require to compile an annotation property against an enumeration type and >>>> load it against another class where the enumeration was turned into an >>>> annotation. I struggled a bit with jtreg to make it work but I cannot see >>>> myself complete this in a meaningful amount of time. However, I hope that >>>> the patch and the error it solves are straightforward to see. >>>> >>>> I only submitted a patch for 8202469. 8202473 is solved by it. It's two >>>> bugs but they are a symptom of the same oversight. >>>> >>>> I hope this helps you to review it but let me know if you have any >>>> questions or if I should further adjust my patch. >>>> >>>> Best regards, Rafael >>>> >>>> Am Fr., 2. Aug. 2019 um 12:18 Uhr schrieb Rafael Winterhalter < >>>> rafael.wth at gmail.com>: >>>> >>>>> Thanks Daniel, >>>>> I did some work on Glassfish a bunch of years ago, I had no idea. >>>>> I will try to split up the changes (I fixed another bug in annotation >>>>> processing yesterday) and upload everything there. >>>>> Best regards, Rafael >>>>> >>>>> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs < >>>>> daniel.fuchs at oracle.com>: >>>>> >>>>>> Hi Rafael, >>>>>> >>>>>> On 02/08/2019 09:00, Joel Borggr?n-Franck wrote: >>>>>> > I can host webrevs for you on cr to make it easier for other >>>>>> reviewers, if >>>>>> > you also send me the patches or webrefs off-list to get around the >>>>>> > attachment stripping I can upload them to cr. >>>>>> >>>>>> I see that you are a JDK project author, so you already own a page >>>>>> on cr (http://cr.openjdk.java.net/~winterhalter/) where you can >>>>>> upload webrevs (e.g. using `scp` as in: >>>>>> \$ scp -r webrev-NNNNN.01 winterhalter at cr.openjdk.java.net: ) >>>>>> >>>>>> best regards and welcome! >>>>>> >>>>>> -- daniel >>>>>> >>>>> From amy.lu at oracle.com Mon Apr 6 12:28:24 2020 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Apr 2020 20:28:24 +0800 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: References: Message-ID: Hi, Roger I noticed some other minor cleanup needed, will they be included in this fix, or separately in the future? 1. test/jdk/TEST.groups To remove `sun/tools/java` from core_tools and svc_tools group. (The only one test under `sun/tools/java` got removed in this patch.) 2. doc/building.md and doc/building.html, both mention rmic tool. 3. langtools tests module:jdk.rmic ./test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list ??????????????????? new String[] {"jdk.compiler", "jdk.rmic"}, ??????????????????? new String[] {"jdk.compiler", "jdk.javadoc", "jdk.rmic"}, ??????????????????? new String[] {"java.compiler", "jdk.compiler", "jdk.rmic"}, ??????????????????? new String[] {"java.compiler", "jdk.compiler", "jdk.javadoc", "jdk.rmic"}, ./test/langtools/tools/jdeps/modules/InverseDeps.java 4. hotspot tests ?* @summary run CTW for all classes from jdk.rmic module ?* @modules jdk.rmic ?* @run driver/timeout=7200 sun.hotspot.tools.ctw.CtwRunner modules:jdk.rmic ./test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java ???????????????????????? "sun/rmi/rmic/Main", ./test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java ??????? //???? sun.rmi.rmic.Main (testcase 4), ???????????? {"Loading non-shared app module class first", "sun.rmi.rmic", ????????????? "sun.rmi.rmic.RMIGenerator", "sun.rmi.rmic.Main"}, ./test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassPackage.java "sun/rmi/rmic/Main", ./test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java Thanks, Amy On 4/3/20 11:43 PM, Roger Riggs wrote: > Please review the CSR[1] and changes to remove the RMI static stub > compiler (rmic). > RMIC was deprecated for removal in JDK 13 [3]. > > The components modified are: > ?- remove the jdk.rmic module > ?- remove the jdk.rmic man page > ?- remove all tests of rmic or relying on rmic > ?- update or remove makefiles to remove references and dependencies on > rmic > ?- update source files in java.rmi module to remove extraneous > references to rmic > > Wevrev: > http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 > > Thanks, Roger > > [1] CSR: > https://bugs.openjdk.java.net/browse/JDK-8242049 > > [2] Issue: > https://bugs.openjdk.java.net/browse/JDK-8225319 > > [3] Deprecate rmic for removal > https://bugs.openjdk.java.net/browse/JDK-8217412 > From james.laskey at oracle.com Mon Apr 6 14:40:04 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Apr 2020 11:40:04 -0300 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks Message-ID: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> Please take the time to review the code changes to remove preview status for String::stripIndent, String::translateEscapes and String::formatted. The changes are pretty light-weight and shouldn't take too long to review. Mostly involves removing "preview" trappings. Cheers, -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 JBS: https://bugs.openjdk.java.net/browse/JDK-8241742 CSR: https://bugs.openjdk.java.net/browse/JDK-8241747 JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 From Roger.Riggs at oracle.com Mon Apr 6 15:25:59 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 6 Apr 2020 11:25:59 -0400 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: References: Message-ID: <61478f2a-b49e-757b-ce96-52d9da51344c@oracle.com> Hi Amy, Thanks for looking in places I didn't grep for rmic references. Hotspot for cds and langtools for javadoc. The webrev is covers just the new changes but I will merge them before the push. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc/ Thanks, Roger On 4/6/20 8:28 AM, Amy Lu wrote: > Hi, Roger > > I noticed some other minor cleanup needed, will they be included in > this fix, or separately in the future? > > 1. test/jdk/TEST.groups > To remove `sun/tools/java` from core_tools and svc_tools group. (The > only one test under `sun/tools/java` got removed in this patch.) > > 2. doc/building.md and doc/building.html, both mention rmic tool. > > 3. langtools tests > module:jdk.rmic > ./test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list > ??????????????????? new String[] {"jdk.compiler", "jdk.rmic"}, > ??????????????????? new String[] {"jdk.compiler", "jdk.javadoc", > "jdk.rmic"}, > ??????????????????? new String[] {"java.compiler", "jdk.compiler", > "jdk.rmic"}, > ??????????????????? new String[] {"java.compiler", "jdk.compiler", > "jdk.javadoc", "jdk.rmic"}, > ./test/langtools/tools/jdeps/modules/InverseDeps.java > > 4. hotspot tests > ?* @summary run CTW for all classes from jdk.rmic module > ?* @modules jdk.rmic > ?* @run driver/timeout=7200 sun.hotspot.tools.ctw.CtwRunner > modules:jdk.rmic > ./test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java > ???????????????????????? "sun/rmi/rmic/Main", > ./test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java > ??????? //???? sun.rmi.rmic.Main (testcase 4), > ???????????? {"Loading non-shared app module class first", > "sun.rmi.rmic", > ????????????? "sun.rmi.rmic.RMIGenerator", "sun.rmi.rmic.Main"}, > ./test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassPackage.java > > "sun/rmi/rmic/Main", > ./test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java > > Thanks, > Amy > > > On 4/3/20 11:43 PM, Roger Riggs wrote: >> Please review the CSR[1] and changes to remove the RMI static stub >> compiler (rmic). >> RMIC was deprecated for removal in JDK 13 [3]. >> >> The components modified are: >> ?- remove the jdk.rmic module >> ?- remove the jdk.rmic man page >> ?- remove all tests of rmic or relying on rmic >> ?- update or remove makefiles to remove references and dependencies >> on rmic >> ?- update source files in java.rmi module to remove extraneous >> references to rmic >> >> Wevrev: >> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 >> >> Thanks, Roger >> >> [1] CSR: >> https://bugs.openjdk.java.net/browse/JDK-8242049 >> >> [2] Issue: >> https://bugs.openjdk.java.net/browse/JDK-8225319 >> >> [3] Deprecate rmic for removal >> https://bugs.openjdk.java.net/browse/JDK-8217412 >> > From james.laskey at oracle.com Mon Apr 6 15:54:45 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Apr 2020 12:54:45 -0300 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks In-Reply-To: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> References: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 > On Apr 6, 2020, at 11:40 AM, Jim Laskey wrote: > > Please take the time to review the code changes to remove preview status for String::stripIndent, String::translateEscapes and String::formatted. The changes are pretty light-weight and shouldn't take too long to review. Mostly involves removing "preview" trappings. > > Cheers, > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241742 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241747 > JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 > > From paul.sandoz at oracle.com Mon Apr 6 16:03:51 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 6 Apr 2020 09:03:51 -0700 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks In-Reply-To: References: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> Message-ID: +1 Paul. > On Apr 6, 2020, at 8:54 AM, Jim Laskey wrote: > > Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 > >> On Apr 6, 2020, at 11:40 AM, Jim Laskey wrote: >> >> Please take the time to review the code changes to remove preview status for String::stripIndent, String::translateEscapes and String::formatted. The changes are pretty light-weight and shouldn't take too long to review. Mostly involves removing "preview" trappings. >> >> Cheers, >> >> -- Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8241742 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8241747 >> JEP: https://bugs.openjdk.java.net/browse/JDK-8236934 >> >> > From chris.hegarty at oracle.com Mon Apr 6 16:07:17 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Apr 2020 17:07:17 +0100 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks In-Reply-To: References: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> Message-ID: <1248F60B-8315-4B67-9518-44C0A8219164@oracle.com> > On 6 Apr 2020, at 17:03, Paul Sandoz wrote: > > ... >> On Apr 6, 2020, at 8:54 AM, Jim Laskey wrote: >> >> Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 Woohoo. LGTM. -Chris. From vipinsharma85 at gmail.com Mon Apr 6 16:07:38 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Mon, 6 Apr 2020 21:37:38 +0530 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> Message-ID: Hi David, I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net Please suggest if there is any way I can create my user id to upload this patch. This is ~300 line patch file. Regards, Vipin > On Apr 6, 2020, at 3:25 AM, David Holmes wrote: > > Hi Vipin, > > On 6/04/2020 6:42 am, Vipin Sharma wrote: >> Hi, >> I have fixed a few warnings where the method parameter name is different in >> code and Javadoc, need a sponsor for this patch. >> Webrev is available at >> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e > > webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. > > Thanks, > David > >> Regards, >> Vipin From Alan.Bateman at oracle.com Mon Apr 6 17:12:39 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Apr 2020 18:12:39 +0100 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks In-Reply-To: References: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> Message-ID: <88c4856a-108d-9660-9a3f-d4c657ac1599@oracle.com> On 06/04/2020 16:54, Jim Laskey wrote: > Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 > > I assume this this updated webrev: ? http://cr.openjdk.java.net/~jlaskey/8241742/webrev-01/ I asked Jim off-list about the @since tags and whether they need to be updated. Alex updated JEP 12 with direction on that so I assume they will be changed to @since 15. Minor nit in the tests is that Formatted has "bug" rather than "@bug" in the test meta data. -Alan From Alan.Bateman at oracle.com Mon Apr 6 17:20:53 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Apr 2020 18:20:53 +0100 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: References: Message-ID: <9a5f06ec-960d-243d-fef9-8ed1b7208254@oracle.com> On 03/04/2020 16:43, Roger Riggs wrote: > Please review the CSR[1] and changes to remove the RMI static stub > compiler (rmic). > RMIC was deprecated for removal in JDK 13 [3]. > > The components modified are: > ?- remove the jdk.rmic module > ?- remove the jdk.rmic man page > ?- remove all tests of rmic or relying on rmic > ?- update or remove makefiles to remove references and dependencies on > rmic > ?- update source files in java.rmi module to remove extraneous > references to rmic > > Wevrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 The javadoc updates and the other changes in the webrev look good. The second webrev with other removals that Amy brought up look good too. I updated the CSR to provide a bit more history and focus it more on the interfaces that are removed rather than the source code view. -Alan From james.laskey at oracle.com Mon Apr 6 17:30:13 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 6 Apr 2020 14:30:13 -0300 Subject: RFR: JDK-8241742 - Remove the preview status for methods introduced for Text Blocks In-Reply-To: <88c4856a-108d-9660-9a3f-d4c657ac1599@oracle.com> References: <58D97681-8E9C-4114-9F3B-C6919930CC54@oracle.com> <88c4856a-108d-9660-9a3f-d4c657ac1599@oracle.com> Message-ID: <11188EA3-2BB5-41EC-BD59-9E27C7A1F251@oracle.com> fixed the @bug - thx Alan > On Apr 6, 2020, at 2:12 PM, Alan Bateman wrote: > > On 06/04/2020 16:54, Jim Laskey wrote: >> Updated webrev: http://cr.openjdk.java.net/~jlaskey/8241742/webrev-00 >> >> > I assume this this updated webrev: > http://cr.openjdk.java.net/~jlaskey/8241742/webrev-01/ > > I asked Jim off-list about the @since tags and whether they need to be updated. Alex updated JEP 12 with direction on that so I assume they will be changed to @since 15. > > Minor nit in the tests is that Formatted has "bug" rather than "@bug" in the test meta data. > > -Alan > > > From henry.jen at oracle.com Mon Apr 6 17:36:05 2020 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 6 Apr 2020 10:36:05 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> Message-ID: <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> Here is the combined webrev[1] which I think is what we should have. By using __solaris__, we make sure no extra define from build and assuming that all solaris build will have gethrtime() and use that. The current build only use that for static build launcher, not custom launcher use libjli. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/ > On Apr 5, 2020, at 9:21 PM, David Holmes wrote: > > On 6/04/2020 12:37 pm, David Holmes wrote: >> On 6/04/2020 12:20 pm, Henry Jen wrote: >>> On Apr 5, 2020, at 7:15 PM, David Holmes wrote: >>>> >>>> On 6/04/2020 11:50 am, David Holmes wrote: >>>>> There is something not right here ... >>>>> On 4/04/2020 3:13 pm, Henry Jen wrote: >>>>>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >>>>>> >>>>>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >>>>> Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >>>>>>> [2020-04-03T16:02:10,984Z] >>>>>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >>>>>>> [2020-04-03T16:02:11,051Z] >>>>>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >>>>>>> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >>>>>>> [2020-04-03T16:02:11,061Z] Undefined first referenced >>>>>>> [2020-04-03T16:02:11,061Z] symbol in file >>>>>>> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>>>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >>>>> This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. >>>> >>>> I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. >>>> >>> >>> I should say it?s the inconsistency for building java.c for launcher executable and libjli.so, thus cause libjli.so failed to build. It wasn?t detected before because CounterGet is defined as no-op, so nothing to link with. >> My point is that this seems completely broken. HAVE_GETHRTIME is never defined when building libjli, only when building the launcher executables, and the launcher executable code never calls CounterGet(). This suggests that the launcher debug code on Solaris has been using the same code as linux and thus should be seen to be reporting the same thing ... which it is ... >> _JAVA_LAUNCHER_DEBUG=true /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java -version >> ----_JAVA_LAUNCHER_DEBUG---- >> Launcher state: >> First application arg index: -1 >> debug:on >> javargs:off >> program name:java >> launcher name:java >> javaw:off >> fullversion:9+181 >> Command line args: >> argv[0] = /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java >> argv[1] = -version >> JRE path is .../java_re/jdk/9/fcs/181/binaries/solaris-x64 >> jvm.cfg[0] = ->-server<- >> jvm.cfg[1] = ->-client<- >> 1 micro seconds to parse jvm.cfg >> Default VM: server >> Does `.../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so' exist ... yes. >> mustsetenv: FALSE >> JVM path is .../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so >> 1 micro seconds to LoadJavaVM >> Always reports 1 microsecond just like Linux. >> This whole setup is completely broken at the build level. > > This worked correctly in JDK 6 (6u181 is latest I could test) but is broken in JDK 7. > > David > ----- > >> Cheers, >> David >>> Cheers, >>> Henry >>> >>> >>>> David >>>> >>>>> David >>>>> ----- >>>>>>> [2020-04-03T16:02:11,082Z] >>>>>>> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>>>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>>>>> [2020-04-03T16:02:11,094Z] >>>>>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>>>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >>>>>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >>>>>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>>>>> [2020-04-03T16:02:11,741Z] >>>>>> >>>>>> >>>>>> I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. >>>>>> >>>>>> As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. >>>>>> >>>>>> I?ll push [2] once I got a +1. >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>>>>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >>>>>>> >>>>>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>>>>> : >>>>>>>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>>>>> Thanks for your help! >>>>>>>> >>>>>>> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >>>>>>> >>>>>>> -Alan. From christoph.dreis at freenet.de Mon Apr 6 17:49:30 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Mon, 06 Apr 2020 19:49:30 +0200 Subject: [NEW BUG] Reduce allocations from Class.toString() for primitives Message-ID: <9B3D62BC-D679-4F58-9021-475A4D92BF5C@freenet.de> Hi, I just noticed an opportunity to optimize Class.toString() for primitive types. I've written a small benchmark and ran it against JDK 15 vs a patched variant. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private Class primitive = long.class; private Class clazz = Long.class; private Class interfaze = Map.class; } @Benchmark public String testPrimitive(ThreadState threadState) { return threadState.primitive.toString(); } @Benchmark public String testClass(ThreadState threadState) { return threadState.clazz.toString(); } @Benchmark public String testInterface(ThreadState threadState) { return threadState.interfaze.toString(); } } This yields the following results: Before Benchmark Mode Cnt Score Error Units MyBenchmark.testClass avgt 10 32,268 ? 2,961 ns/op MyBenchmark.testClass:?gc.alloc.rate avgt 10 3601,964 ? 336,786 MB/sec MyBenchmark.testClass:?gc.alloc.rate.norm avgt 10 152,009 ? 0,001 B/op MyBenchmark.testClass:?gc.count avgt 10 203,000 counts MyBenchmark.testClass:?gc.time avgt 10 138,000 ms MyBenchmark.testInterface avgt 10 37,685 ? 3,728 ns/op MyBenchmark.testInterface:?gc.alloc.rate avgt 10 3086,794 ? 309,983 MB/sec MyBenchmark.testInterface:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op MyBenchmark.testInterface:?gc.count avgt 10 160,000 counts MyBenchmark.testInterface:?gc.time avgt 10 107,000 ms MyBenchmark.testPrimitive avgt 10 20,937 ? 2,668 ns/op MyBenchmark.testPrimitive:?gc.alloc.rate avgt 10 3809,437 ? 470,140 MB/sec MyBenchmark.testPrimitive:?gc.alloc.rate.norm avgt 10 104,006 ? 0,001 B/op MyBenchmark.testPrimitive:?gc.count avgt 10 215,000 counts MyBenchmark.testPrimitive:?gc.time avgt 10 167,000 ms After Benchmark Mode Cnt Score Error Units MyBenchmark.testClass avgt 10 31,585 ? 5,365 ns/op MyBenchmark.testClass:?gc.alloc.rate avgt 10 3704,714 ? 549,224 MB/sec MyBenchmark.testClass:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op MyBenchmark.testClass:?gc.count avgt 10 191,000 counts MyBenchmark.testClass:?gc.time avgt 10 139,000 ms MyBenchmark.testInterface avgt 10 34,534 ? 2,073 ns/op MyBenchmark.testInterface:?gc.alloc.rate avgt 10 3358,401 ? 193,391 MB/sec MyBenchmark.testInterface:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op MyBenchmark.testInterface:?gc.count avgt 10 173,000 counts MyBenchmark.testInterface:?gc.time avgt 10 131,000 ms MyBenchmark.testPrimitive avgt 10 2,829 ? 0,139 ns/op MyBenchmark.testPrimitive:?gc.alloc.rate avgt 10 ? 10?? MB/sec MyBenchmark.testPrimitive:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.testPrimitive:?gc.count avgt 10 ? 0 counts I don't think the patched version is actually faster for classes & interfaces; I guess it's rather a draw for those. Yet, for primitives we can see a 10x improvement due to the avoided string concats. In case you think this is worthwhile I would need someone to sponsor this patch. I would highly appreciate that. Let me know what you think Cheers, Christoph ===== PATCH ===== diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java +++ b/src/java.base/share/classes/java/lang/Class.java @@ -196,8 +196,11 @@ * @return a string representation of this {@code Class} object. */ public String toString() { - return (isInterface() ? "interface " : (isPrimitive() ? "" : "class ")) - + getName(); + String name = getName(); + if (isPrimitive()) { + return name; + } + return (isInterface() ? "interface " : "class ") + name; } From claes.redestad at oracle.com Mon Apr 6 18:31:47 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 6 Apr 2020 20:31:47 +0200 Subject: [NEW BUG] Reduce allocations from Class.toString() for primitives In-Reply-To: <9B3D62BC-D679-4F58-9021-475A4D92BF5C@freenet.de> References: <9B3D62BC-D679-4F58-9021-475A4D92BF5C@freenet.de> Message-ID: Hi Christoph, while the patch seems ok, I fail to think of a scenario where performance of Class.toString() might be critical. Also it seems this code is subject to change via valhalla[1]. So I think I'll say no, for once. :-) Thanks! /Claes [1] https://github.com/openjdk/valhalla/blob/lworld/src/java.base/share/classes/java/lang/Class.java#L197 On 2020-04-06 19:49, Christoph Dreis wrote: > Hi, > > I just noticed an opportunity to optimize Class.toString() for primitive types. > > I've written a small benchmark and ran it against JDK 15 vs a patched variant. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private Class primitive = long.class; > private Class clazz = Long.class; > private Class interfaze = Map.class; > > } > > @Benchmark > public String testPrimitive(ThreadState threadState) { > return threadState.primitive.toString(); > } > > @Benchmark > public String testClass(ThreadState threadState) { > return threadState.clazz.toString(); > } > > @Benchmark > public String testInterface(ThreadState threadState) { > return threadState.interfaze.toString(); > } > > } > > This yields the following results: > > Before > Benchmark Mode Cnt Score Error Units > MyBenchmark.testClass avgt 10 32,268 ? 2,961 ns/op > MyBenchmark.testClass:?gc.alloc.rate avgt 10 3601,964 ? 336,786 MB/sec > MyBenchmark.testClass:?gc.alloc.rate.norm avgt 10 152,009 ? 0,001 B/op > MyBenchmark.testClass:?gc.count avgt 10 203,000 counts > MyBenchmark.testClass:?gc.time avgt 10 138,000 ms > MyBenchmark.testInterface avgt 10 37,685 ? 3,728 ns/op > MyBenchmark.testInterface:?gc.alloc.rate avgt 10 3086,794 ? 309,983 MB/sec > MyBenchmark.testInterface:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op > MyBenchmark.testInterface:?gc.count avgt 10 160,000 counts > MyBenchmark.testInterface:?gc.time avgt 10 107,000 ms > MyBenchmark.testPrimitive avgt 10 20,937 ? 2,668 ns/op > MyBenchmark.testPrimitive:?gc.alloc.rate avgt 10 3809,437 ? 470,140 MB/sec > MyBenchmark.testPrimitive:?gc.alloc.rate.norm avgt 10 104,006 ? 0,001 B/op > MyBenchmark.testPrimitive:?gc.count avgt 10 215,000 counts > MyBenchmark.testPrimitive:?gc.time avgt 10 167,000 ms > > > After > Benchmark Mode Cnt Score Error Units > MyBenchmark.testClass avgt 10 31,585 ? 5,365 ns/op > MyBenchmark.testClass:?gc.alloc.rate avgt 10 3704,714 ? 549,224 MB/sec > MyBenchmark.testClass:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op > MyBenchmark.testClass:?gc.count avgt 10 191,000 counts > MyBenchmark.testClass:?gc.time avgt 10 139,000 ms > MyBenchmark.testInterface avgt 10 34,534 ? 2,073 ns/op > MyBenchmark.testInterface:?gc.alloc.rate avgt 10 3358,401 ? 193,391 MB/sec > MyBenchmark.testInterface:?gc.alloc.rate.norm avgt 10 152,008 ? 0,001 B/op > MyBenchmark.testInterface:?gc.count avgt 10 173,000 counts > MyBenchmark.testInterface:?gc.time avgt 10 131,000 ms > MyBenchmark.testPrimitive avgt 10 2,829 ? 0,139 ns/op > MyBenchmark.testPrimitive:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.testPrimitive:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.testPrimitive:?gc.count avgt 10 ? 0 counts > > I don't think the patched version is actually faster for classes & interfaces; I guess it's rather a draw for those. > Yet, for primitives we can see a 10x improvement due to the avoided string concats. > > In case you think this is worthwhile I would need someone to sponsor this patch. > I would highly appreciate that. Let me know what you think > > Cheers, > Christoph > > > ===== PATCH ===== > diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java > +++ b/src/java.base/share/classes/java/lang/Class.java > @@ -196,8 +196,11 @@ > * @return a string representation of this {@code Class} object. > */ > public String toString() { > - return (isInterface() ? "interface " : (isPrimitive() ? "" : "class ")) > - + getName(); > + String name = getName(); > + if (isPrimitive()) { > + return name; > + } > + return (isInterface() ? "interface " : "class ") + name; > } > > From pavel.rappo at oracle.com Mon Apr 6 18:28:38 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 6 Apr 2020 19:28:38 +0100 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting Message-ID: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affected: java.lang, java.text, java.util, java.util.logging, javax.lang.model.util, jdk.internal.reflect -Pavel From mandy.chung at oracle.com Mon Apr 6 18:54:11 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 6 Apr 2020 11:54:11 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: > > The suggested fix is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ > This patch looks okay. I'll include in my local patch. On 4/6/20 11:00 AM, Chris Plummer wrote: > > I think that's fine but I don't think it should be done in the context > of this Vahalla webrev since it has nothing to do with Vahalla. I'd > suggest filing an RFE and pushing it to jdk/jdk. Easier to track that > way if there are issues down the road. > I am okay to follow up as a separate RFE. thanks Mandy From viv.desh at gmail.com Mon Apr 6 18:55:05 2020 From: viv.desh at gmail.com (Vivek Deshpande) Date: Mon, 6 Apr 2020 11:55:05 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes In-Reply-To: References: Message-ID: Hi Sandhya I looked at the patch over the weekend. It looks good to me and a lot of work is involved. I have a question. Is this patch intended to panama/dev or mainline jdk? Nit: macroAssembler_x86.cpp has extra line at 115. Regards, Vivek OpenJDK id: vdeshpande On Fri, Apr 3, 2020 at 5:18 PM Viswanathan, Sandhya < sandhya.viswanathan at intel.com> wrote: > Hi, > > > Following up on review requests of API [0], Java implementation [1] and > > General Hotspot changes[3] for Vector API, here's a request for review > > of x86 backend changes required for supporting the API: > > > > JEP: https://openjdk.java.net/jeps/338 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > > Webrev: > http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ > > > > Complete implementation resides in vector-unstable branch of > > panama/dev repository [3]. > > Looking forward to your feedback. > > Best Regards, > Sandhya > > > [0] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html > > > > [2] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html > > > > [3] https://openjdk.java.net/projects/panama/ > > \$ hg clone http://hg.openjdk.java.net/panama/dev/ -b > vector-unstable > > > > > > -- Thanks and Regards, Vivek Deshpande viv.desh at gmail.com From sandhya.viswanathan at intel.com Mon Apr 6 19:01:17 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 6 Apr 2020 19:01:17 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes In-Reply-To: References: Message-ID: Hi Vivek, Thanks for the feedback. This patch is for mainline jdk. Best Regards, Sandhya From: Vivek Deshpande Sent: Monday, April 06, 2020 11:55 AM To: Viswanathan, Sandhya Cc: hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes Hi Sandhya I looked at the patch over the weekend. It looks good to me and a lot of work is involved. I have a question. Is this patch intended to panama/dev or mainline jdk? Nit: macroAssembler_x86.cpp has extra line at 115. Regards, Vivek OpenJDK id: vdeshpande On Fri, Apr 3, 2020 at 5:18 PM Viswanathan, Sandhya > wrote: Hi, Following up on review requests of API [0], Java implementation [1] and General Hotspot changes[3] for Vector API, here's a request for review of x86 backend changes required for supporting the API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ Complete implementation resides in vector-unstable branch of panama/dev repository [3]. Looking forward to your feedback. Best Regards, Sandhya [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://openjdk.java.net/projects/panama/ \$ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable -- Thanks and Regards, Vivek Deshpande viv.desh at gmail.com From serguei.spitsyn at oracle.com Mon Apr 6 19:08:46 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 12:08:46 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 11:54, Mandy Chung wrote: > On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: >> >> The suggested fix is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ >> > > This patch looks okay. I'll include in my local patch. > > On 4/6/20 11:00 AM, Chris Plummer wrote: >> >> I think that's fine but I don't think it should be done in the >> context of this Vahalla webrev since it has nothing to do with >> Vahalla. I'd suggest filing an RFE and pushing it to jdk/jdk. Easier >> to track that way if there are issues down the road. >> > > I am okay to follow up as a separate RFE. Filed RFE: ? https://bugs.openjdk.java.net/browse/JDK-8242241 ??? add assert to ClassUnloadEventImpl::className Thanks, Serguei > > thanks > Mandy From alexey.semenyuk at oracle.com Mon Apr 6 22:39:22 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 6 Apr 2020 18:39:22 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> Message-ID: Looks good. - Alexey On 4/4/2020 8:53 AM, Andy Herrick wrote: > I think it best to modify these checks as part of a separate issue, > and leave these checks disabled as part of JDK-8237490.? I have filed > JDK-8242155 to enhance these tests, including restoring these checks. > > /ANdy > > On 4/3/2020 7:29 PM, Alexander Matveev wrote: >> Hi Andy, >> >> http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html >> >> Maybe better to check for Catalina case as well, instead of disabling >> check. We can assume that on Catalina code 3 and not notarized will >> consider as pass. In case if it fails for some other reasons. >> >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 4/3/20 7:20 AM, Andy Herrick wrote: >>> sorry missing webrev pointer [4] >>> >>> [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 >>> >>> /Andy >>> >>> On 4/3/2020 9:24 AM, Andy Herrick wrote: >>>> please review this revised webrev [4] to issue [2] >>>> >>>> The previous version generated a signed app that could be >>>> notarized, but then couldn't run because signing the whole app >>>> resigned the executable with reduced entitlements. >>>> >>>> This revision adds back in the entitlements when signing the whole >>>> app, as well as fixing the unit test that was failing the spctl >>>> call on Catalina due to signed app not being notarized. >>>> >>>> >>>> /Andy >>>> >>>> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>>>> revised with minor fixes as per below - webrev at [3] >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>>>> >>>>> /Andy >>>>> >>>>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>>>> >>>>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>>>> >>>>>>> Line 819,857,902 - Looks like temp debug log message. Remove it >>>>>>> or align with rest of code. >>>>>> I will fix this. >>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>>>> >>>>>>> Line 70 - Capital F. >>>>>> and this >>>>>>> >>>>>>> Since we added "--timestamp" and? "--options runtime" to >>>>>>> codesign, will it work with older Xcode and macOS we planning to >>>>>>> support? >>>>>> not sure - may need some discussion of what we support and >>>>>> possible conditional code here. >>>>>>> >>>>>>> Do we need any adjustments to signing tests we have? >>>>>> >>>>>> The existing tests pass, but this is not unexpected (and really >>>>>> means nothing) since the signing tests are all skipped unless >>>>>> specific test certs are installed on target machine. >>>>>> >>>>>> We need further discussion how one is expected to provision a >>>>>> machine to run these tests. >>>>>> >>>>>> /Andy >>>>>> >>>>>>> >>>>>>> Otherwise looks fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>>>> Please review the fix to issue [1] at [2]. >>>>>>>> >>>>>>>> This change enables notarization on Mac for dmg images and >>>>>>>> app-image zip files. >>>>>>>> >>>>>>>> /Andy >>>>>>>> >>>>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>>>> >>>>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>>>> >>>>>>> >> From david.holmes at oracle.com Mon Apr 6 23:29:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Apr 2020 09:29:16 +1000 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> Message-ID: <61d1744c-6a8a-8d92-4493-e06e35c69acc@oracle.com> Hi Vipin, On 7/04/2020 2:07 am, Vipin Sharma wrote: > Hi David, > > I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net > Please suggest if there is any way I can create my user id to upload this patch. No - as you note at this stage you need a sponsor to create the bug for you and host the webrev if you can't inline to the mailing list. Hopefully someone from core-libs will offer to do that soon. Thanks, David > This is ~300 line patch file. > > Regards, > Vipin > >> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >> >> Hi Vipin, >> >> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>> Hi, >>> I have fixed a few warnings where the method parameter name is different in >>> code and Javadoc, need a sponsor for this patch. >>> Webrev is available at >>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >> >> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >> >> Thanks, >> David >> >>> Regards, >>> Vipin > From joe.darcy at oracle.com Mon Apr 6 23:37:27 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 6 Apr 2020 16:37:27 -0700 Subject: JDK 15 RFR of JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations Message-ID: Hello, Please review the changes to fix ??? JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations ??? http://cr.openjdk.java.net/~darcy/8225540.1/ This is a sibling fix to JDK-8225495 already done over in javax.lang.model. In brief, the purpose of the change is to make explicit whether declaration annotations (that is traditional annotations in the platform since JDK 5.0) or type annotations (added in JDK 8) are being returned by the various annotation-returning methods. The distinctions between the two kinds of annotations are discussed in the cited sections of JLS. The root interface of types that can return annotations is AnnotatedElement. Some of the wording developed for JDK-8225495 is borrowed and repurposed as a general explanation in AnnotatedElement.? The implementation specification of the default method for AnnotatedElement.isAnnotationPresetn is pull out to properly use an @implSpec tag. The AnnotatedType interface and its subinterfaces return type annotations; the other class and interfaces return declaration annotations. For AnnotatedType, the three methods on AnnotatedElement that do *not* have default methods are overriden for the sole purpose of adding a note stating any return annotations are *type* annotations. The specs of the default methods rely on the behavior of the non-default methods so this implicitly implies the results of the other methods are type annotations too. Since there is no common superclass of the various classes which can return declaration annotations, analogous notes are spread through many classes including ??? * java.lang.Class ??? * java.lang.Package ??? * java.lang.Module ??? * java.reflect.{AccessibleObject, Executable, Constructor, Method, Field, Parameter, RecordComponent} These classes are also updated to use @Override consistently for the annotation-related methods; @Override couldn't initially be used on interface methods implemented by a class. The Executable.getParameterAnnotations method also get a note to state it returns declaration annotations. I'll update copyright and reflow paragraphs before pushing. Thanks, -Joe From david.holmes at oracle.com Tue Apr 7 02:43:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Apr 2020 12:43:26 +1000 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> Message-ID: Hi Henry, On 7/04/2020 3:36 am, Henry Jen wrote: > Here is the combined webrev[1] which I think is what we should have. By using __solaris__, we make sure no extra define from build and assuming that all solaris build will have gethrtime() and use that. This looks good to me and means the Solaris code should start working correctly again, as well as providing an implementation on all other platforms. Only minor suggestion is to move 33 #include outside of the ifdef in the header file as all platforms will include it anyway. You can then also remove the include in the .c file 819 #include Thanks, David ----- > The current build only use that for static build launcher, not custom launcher use libjli. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/ > >> On Apr 5, 2020, at 9:21 PM, David Holmes wrote: >> >> On 6/04/2020 12:37 pm, David Holmes wrote: >>> On 6/04/2020 12:20 pm, Henry Jen wrote: >>>> On Apr 5, 2020, at 7:15 PM, David Holmes wrote: >>>>> >>>>> On 6/04/2020 11:50 am, David Holmes wrote: >>>>>> There is something not right here ... >>>>>> On 4/04/2020 3:13 pm, Henry Jen wrote: >>>>>>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >>>>>>> >>>>>>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >>>>>> Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >>>>>>>> [2020-04-03T16:02:10,984Z] >>>>>>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >>>>>>>> [2020-04-03T16:02:11,051Z] >>>>>>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >>>>>>>> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >>>>>>>> [2020-04-03T16:02:11,061Z] Undefined first referenced >>>>>>>> [2020-04-03T16:02:11,061Z] symbol in file >>>>>>>> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>>>>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >>>>>> This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. >>>>> >>>>> I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. >>>>> >>>> >>>> I should say it?s the inconsistency for building java.c for launcher executable and libjli.so, thus cause libjli.so failed to build. It wasn?t detected before because CounterGet is defined as no-op, so nothing to link with. >>> My point is that this seems completely broken. HAVE_GETHRTIME is never defined when building libjli, only when building the launcher executables, and the launcher executable code never calls CounterGet(). This suggests that the launcher debug code on Solaris has been using the same code as linux and thus should be seen to be reporting the same thing ... which it is ... >>> _JAVA_LAUNCHER_DEBUG=true /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java -version >>> ----_JAVA_LAUNCHER_DEBUG---- >>> Launcher state: >>> First application arg index: -1 >>> debug:on >>> javargs:off >>> program name:java >>> launcher name:java >>> javaw:off >>> fullversion:9+181 >>> Command line args: >>> argv[0] = /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java >>> argv[1] = -version >>> JRE path is .../java_re/jdk/9/fcs/181/binaries/solaris-x64 >>> jvm.cfg[0] = ->-server<- >>> jvm.cfg[1] = ->-client<- >>> 1 micro seconds to parse jvm.cfg >>> Default VM: server >>> Does `.../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so' exist ... yes. >>> mustsetenv: FALSE >>> JVM path is .../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so >>> 1 micro seconds to LoadJavaVM >>> Always reports 1 microsecond just like Linux. >>> This whole setup is completely broken at the build level. >> >> This worked correctly in JDK 6 (6u181 is latest I could test) but is broken in JDK 7. >> >> David >> ----- >> >>> Cheers, >>> David >>>> Cheers, >>>> Henry >>>> >>>> >>>>> David >>>>> >>>>>> David >>>>>> ----- >>>>>>>> [2020-04-03T16:02:11,082Z] >>>>>>>> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>>>>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>>>>>> [2020-04-03T16:02:11,094Z] >>>>>>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>>>>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >>>>>>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >>>>>>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>>>>>> [2020-04-03T16:02:11,741Z] >>>>>>> >>>>>>> >>>>>>> I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. >>>>>>> >>>>>>> As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. >>>>>>> >>>>>>> I?ll push [2] once I got a +1. >>>>>>> >>>>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>>>>>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>>>>>> >>>>>>> Cheers, >>>>>>> Henry >>>>>>> >>>>>>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >>>>>>>> >>>>>>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>>>>>> : >>>>>>>>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>>>>>> Thanks for your help! >>>>>>>>> >>>>>>>> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >>>>>>>> >>>>>>>> -Alan. > From henry.jen at oracle.com Tue Apr 7 03:06:01 2020 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 6 Apr 2020 20:06:01 -0700 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> Message-ID: <81ECA75D-02F9-4A93-9E91-6ADA627FAE41@oracle.com> Sure, will change the before I push. I considered that but didn?t run with it. Cheers, Henry > On Apr 6, 2020, at 7:43 PM, David Holmes wrote: > > Hi Henry, > > On 7/04/2020 3:36 am, Henry Jen wrote: >> Here is the combined webrev[1] which I think is what we should have. By using __solaris__, we make sure no extra define from build and assuming that all solaris build will have gethrtime() and use that. > > This looks good to me and means the Solaris code should start working correctly again, as well as providing an implementation on all other platforms. > > Only minor suggestion is to move > > 33 #include > > outside of the ifdef in the header file as all platforms will include it anyway. You can then also remove the include in the .c file > > 819 #include > > Thanks, > David > ----- > >> The current build only use that for static build launcher, not custom launcher use libjli. >> Cheers, >> Henry >> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/ >>> On Apr 5, 2020, at 9:21 PM, David Holmes wrote: >>> >>> On 6/04/2020 12:37 pm, David Holmes wrote: >>>> On 6/04/2020 12:20 pm, Henry Jen wrote: >>>>> On Apr 5, 2020, at 7:15 PM, David Holmes wrote: >>>>>> >>>>>> On 6/04/2020 11:50 am, David Holmes wrote: >>>>>>> There is something not right here ... >>>>>>> On 4/04/2020 3:13 pm, Henry Jen wrote: >>>>>>>> Internal test shows that inline implementation is not working for some Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is actually broken. :) >>>>>>>> >>>>>>>>> [2020-04-03T15:59:26,981Z] Creating support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s) >>>>>>> Are you sure that line actually pertains to any error? The test defines a custom launcher which doesn't use libjli so should never be including the header file we are discussing. >>>>>>>>> [2020-04-03T16:02:10,984Z] >>>>>>>>> [2020-04-03T16:02:10,984Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'solaris-sparcv9-open' (exit code 2) >>>>>>>>> [2020-04-03T16:02:11,051Z] >>>>>>>>> [2020-04-03T16:02:11,051Z] === Output from failing command(s) repeated here === >>>>>>>>> [2020-04-03T16:02:11,055Z] * For target support_native_java.base_libjli_BUILD_LIBJLI_link: >>>>>>>>> [2020-04-03T16:02:11,061Z] Undefined first referenced >>>>>>>>> [2020-04-03T16:02:11,061Z] symbol in file >>>>>>>>> [2020-04-03T16:02:11,061Z] getTimeMicros /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/native/java.base/libjli/java.o >>>>>>>>> [2020-04-03T16:02:11,061Z] ld: fatal: symbol referencing errors >>>>>>> This looks like a direct linkage error. AFAICS ./launcher/LauncherCommon.gmk only defines -DHAVE_GETHRTIME for launcher executables. But if we are building libjli it is not an executable. I'm suspecting there is actually a long standing build bug here from when libjli was introduced. Possibly only evident on an incremental build. >>>>>> >>>>>> I can confirm that the flags set in LauncherCommon.gmk are not passed to the compilation of java_md_solinux.c (I added a custom -DDAVIDH to the linux flags and checked the build). So I have no idea how this has been working, if indeed it actually has. >>>>>> >>>>> >>>>> I should say it?s the inconsistency for building java.c for launcher executable and libjli.so, thus cause libjli.so failed to build. It wasn?t detected before because CounterGet is defined as no-op, so nothing to link with. >>>> My point is that this seems completely broken. HAVE_GETHRTIME is never defined when building libjli, only when building the launcher executables, and the launcher executable code never calls CounterGet(). This suggests that the launcher debug code on Solaris has been using the same code as linux and thus should be seen to be reporting the same thing ... which it is ... >>>> _JAVA_LAUNCHER_DEBUG=true /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java -version >>>> ----_JAVA_LAUNCHER_DEBUG---- >>>> Launcher state: >>>> First application arg index: -1 >>>> debug:on >>>> javargs:off >>>> program name:java >>>> launcher name:java >>>> javaw:off >>>> fullversion:9+181 >>>> Command line args: >>>> argv[0] = /java/re/jdk/9/promoted/latest/binaries/solaris-x64/bin/java >>>> argv[1] = -version >>>> JRE path is .../java_re/jdk/9/fcs/181/binaries/solaris-x64 >>>> jvm.cfg[0] = ->-server<- >>>> jvm.cfg[1] = ->-client<- >>>> 1 micro seconds to parse jvm.cfg >>>> Default VM: server >>>> Does `.../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so' exist ... yes. >>>> mustsetenv: FALSE >>>> JVM path is .../export/java_re/jdk/9/fcs/181/binaries/solaris-x64/lib/server/libjvm.so >>>> 1 micro seconds to LoadJavaVM >>>> Always reports 1 microsecond just like Linux. >>>> This whole setup is completely broken at the build level. >>> >>> This worked correctly in JDK 6 (6u181 is latest I could test) but is broken in JDK 7. >>> >>> David >>> ----- >>> >>>> Cheers, >>>> David >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>>>> David >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>>>> [2020-04-03T16:02:11,082Z] >>>>>>>>> [2020-04-03T16:02:11,082Z] * All command lines available in /export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/make-support/failure-logs. >>>>>>>>> [2020-04-03T16:02:11,086Z] === End of repeated output === >>>>>>>>> [2020-04-03T16:02:11,094Z] >>>>>>>>> [2020-04-03T16:02:11,094Z] === Make failed targets repeated here === >>>>>>>>> [2020-04-03T16:02:11,736Z] CoreLibraries.gmk:206: recipe for target '/export/home/opt/mach5/mesos/work_dir/e101deec-9613-4d46-a64d-559e689496aa/workspace/build/solaris-sparcv9-open/support/modules_libs/java.base/libjli.so' failed >>>>>>>>> [2020-04-03T16:02:11,737Z] make/Main.gmk:195: recipe for target 'java.base-libs' failed >>>>>>>>> [2020-04-03T16:02:11,739Z] === End of repeated output === >>>>>>>>> [2020-04-03T16:02:11,741Z] >>>>>>>> >>>>>>>> >>>>>>>> I verified that either move implementation into .c as a function body[1] or change to #ifdef __solaris__[2] will fix that. So I think we will change to detect __solaris__ as webrev[2] rather than have an extra #define. If some other build want to have that, they can be modify that #ifdef easily. >>>>>>>> >>>>>>>> As I look into it, I found Mac have similar implementation with minor mistake, so I fixed that as well. Please review following based on zhanglin?s patch. >>>>>>>> >>>>>>>> I?ll push [2] once I got a +1. >>>>>>>> >>>>>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.0/webrev/ >>>>>>>> [2] http://cr.openjdk.java.net/~henryjen/jdk/8241638.1/webrev/ >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Henry >>>>>>>> >>>>>>>>> On Apr 2, 2020, at 6:17 AM, Alan Bateman wrote: >>>>>>>>> >>>>>>>>> On 02/04/2020 11:26, linzang(??) wrote: >>>>>>>>>> : >>>>>>>>>> Here is the updated webrev : http://cr.openjdk.java.net/~lzang/8241638/webrev04/ >>>>>>>>>> Thanks for your help! >>>>>>>>>> >>>>>>>>> webrev04 looks good. My preference was to was to replace #ifdef HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem to be appetite to do this now. I think Henry has offered to help sponsor. >>>>>>>>> >>>>>>>>> -Alan. From amy.lu at oracle.com Tue Apr 7 03:26:25 2020 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 7 Apr 2020 11:26:25 +0800 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: <61478f2a-b49e-757b-ce96-52d9da51344c@oracle.com> References: <61478f2a-b49e-757b-ce96-52d9da51344c@oracle.com> Message-ID: Thank you Roger for the additional changes. Looks good. Please remember to update the copyright year for jdk/TEST.groups and hotspot tests before push, and fix the changed year in bin/unshuffle_list.txt (missed a `,` after 2020) (I'm not an official reviewer.) Thanks, Amy On 4/6/20 11:25 PM, Roger Riggs wrote: > Hi Amy, > > Thanks for looking in places I didn't grep for rmic references. > > Hotspot for cds and langtools for javadoc. > > The webrev is covers just the new changes but I will merge them before > the push. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc/ > > Thanks, Roger > > On 4/6/20 8:28 AM, Amy Lu wrote: >> Hi, Roger >> >> I noticed some other minor cleanup needed, will they be included in >> this fix, or separately in the future? >> >> 1. test/jdk/TEST.groups >> To remove `sun/tools/java` from core_tools and svc_tools group. (The >> only one test under `sun/tools/java` got removed in this patch.) >> >> 2. doc/building.md and doc/building.html, both mention rmic tool. >> >> 3. langtools tests >> module:jdk.rmic >> ./test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list >> ??????????????????? new String[] {"jdk.compiler", "jdk.rmic"}, >> ??????????????????? new String[] {"jdk.compiler", "jdk.javadoc", >> "jdk.rmic"}, >> ??????????????????? new String[] {"java.compiler", "jdk.compiler", >> "jdk.rmic"}, >> ??????????????????? new String[] {"java.compiler", "jdk.compiler", >> "jdk.javadoc", "jdk.rmic"}, >> ./test/langtools/tools/jdeps/modules/InverseDeps.java >> >> 4. hotspot tests >> ?* @summary run CTW for all classes from jdk.rmic module >> ?* @modules jdk.rmic >> ?* @run driver/timeout=7200 sun.hotspot.tools.ctw.CtwRunner >> modules:jdk.rmic >> ./test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java >> ???????????????????????? "sun/rmi/rmic/Main", >> ./test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java >> ??????? //???? sun.rmi.rmic.Main (testcase 4), >> ???????????? {"Loading non-shared app module class first", >> "sun.rmi.rmic", >> ????????????? "sun.rmi.rmic.RMIGenerator", "sun.rmi.rmic.Main"}, >> ./test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassPackage.java >> >> "sun/rmi/rmic/Main", >> ./test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java >> >> Thanks, >> Amy >> >> >> On 4/3/20 11:43 PM, Roger Riggs wrote: >>> Please review the CSR[1] and changes to remove the RMI static stub >>> compiler (rmic). >>> RMIC was deprecated for removal in JDK 13 [3]. >>> >>> The components modified are: >>> ?- remove the jdk.rmic module >>> ?- remove the jdk.rmic man page >>> ?- remove all tests of rmic or relying on rmic >>> ?- update or remove makefiles to remove references and dependencies >>> on rmic >>> ?- update source files in java.rmi module to remove extraneous >>> references to rmic >>> >>> Wevrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 >>> >>> Thanks, Roger >>> >>> [1] CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8242049 >>> >>> [2] Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8225319 >>> >>> [3] Deprecate rmic for removal >>> https://bugs.openjdk.java.net/browse/JDK-8217412 >>> >> > From ivan.gerasimov at oracle.com Tue Apr 7 08:11:35 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 7 Apr 2020 01:11:35 -0700 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> Message-ID: <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> Hi Pavel! A couple of comments. 1) java/util/logging/Formatter.java This has one extra open curly brace: "{{@literal }" 2) grep finds some more typos of the same kind that you've spotted. a)? rgrep '^[ ]*\*'|grep ' ,'|less This find number of potential typos.? For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma.? A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. b)? rgrep '^[ ]*\*'|grep '\w- '|less This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java (I only searched under src/java.base) With kind regards, Ivan [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html On 4/6/20 11:28 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: > > http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.text, > java.util, > java.util.logging, > javax.lang.model.util, > jdk.internal.reflect > > -Pavel > -- With kind regards, Ivan Gerasimov From evgeny.nikitin at oracle.com Tue Apr 7 08:33:42 2020 From: evgeny.nikitin at oracle.com (Evgeny Nikitin) Date: Tue, 7 Apr 2020 10:33:42 +0200 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> References: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> Message-ID: Hi David, > I'm not at all sure this is generally what we want for every single > test that uses ProcessTools! But I'm willing it to see it trialed. Well, it's mostly used for test VM runs. In runs I performed (artificial "failures" included) the amounts of output were very small. > Please run full tier testing at least to tier 6 and ideally beyond > before pushing this. There are potential implications for temporary > (and more permanent) disk usage as well as additional time needed to > write files out to disk. (Hopefully these are generally small enough > that this doesn't make a noticeable difference.) Done, thanks for suggestion. The additional runs showed no problems. I've provided Igor with a slightly modified version (Added notification about the output file into the main test's log). Please review: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ Best Regards, Evgeny. On 2020-04-02 02:07, David Holmes wrote: > Thanks for sharing this Igor! > > I'm not at all sure this is generally what we want for every single > test that uses ProcessTools! But I'm willing it to see it trialed. > > Evgeny: Please run full tier testing at least to tier 6 and ideally > beyond before pushing this. There are potential implications for > temporary (and more permanent) disk usage as well as additional time > needed to write files out to disk. (Hopefully these are generally > small enough that this doesn't make a noticeable difference.) > > Thanks, > David > > On 2/04/2020 5:13 am, Igor Ignatyev wrote: >> Hi Evgeny, >> >> (widening the audience, given this affects not just hotspot compiler, >> but hotspot tests as well as core libs tests in general) >> >> overall that looks good to me. one suggestion, for the ease of >> failure analysis it might be worth to print out the names of created >> files, although this might potentially clutter the output, I don't >> think it'll be a problem given we already print out things like >> 'Gathering output for process ...' , 'Waiting for completion...' in >> LazyOutputBuffer. >> >>> The change has been tested via a mach5 test runs (jdk-tier1 through >>> 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, >>> sparcv9). >> this doesn't include any of hotspot tiers, could you please also run >> hs-tier1--4? >> // you can use tierN jobs which include both jdk and hs parts. >> >> Thanks, >> -- Igor >> >>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin >>> wrote: >>> >>> >>> Hi, >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>> >>> >>> The bug had been created as a request to simplify investigation for >>> compiler control tests failures. >>> I found the functionality pretty generic and useful and made >>> ProcessTools dump output as well as some diagnostic information for >>> every executed process into a separate file. >>> The diagnostic information contains cmdline, exit code, stdout and >>> stderr. The output files are named like 'pid--output.log'. >>> >>> The change has been tested via a mach5 test runs (jdk-tier1 through >>> 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, >>> sparcv9). >>> >>> Please review, >>> /Evgeny Nikitin. >> From Alan.Bateman at oracle.com Tue Apr 7 08:53:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Apr 2020 09:53:07 +0100 Subject: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> References: <9A36CE11-5843-4D56-9B57-DA7C186D9ACD@tencent.com> <1fe936a8-66fd-05bd-25ea-11e210792c47@oracle.com> <5304201a-5803-2309-4473-689a3dd7b8a1@oracle.com> <44939041-F87C-449E-A69C-0DDFB3301463@tencent.com> <1e447409-4125-0e93-3789-63c65914ce29@oracle.com> <7A1ABD92-122B-4A09-8DDB-4BFA340081BB@tencent.com> <35804568-7795-423A-98A1-DDB67D03F59A@tencent.com> <97BF5864-9C5C-4235-BEFE-A877FA7E266F@oracle.com> <89e057c9-592e-31e6-4566-9cfc9cbf204d@oracle.com> <392CBBD2-0CA0-42FB-9316-B2A50D53FB4D@oracle.com> <28229a5b-7991-97ff-f277-c5972c007a44@oracle.com> <4d164740-7900-f521-f530-c570e8d2e7c4@oracle.com> <23348D08-12DE-498A-B938-AAE5C242064B@oracle.com> Message-ID: On 06/04/2020 18:36, Henry Jen wrote: > Here is the combined webrev[1] which I think is what we should have. By using __solaris__, we make sure no extra define from build and assuming that all solaris build will have gethrtime() and use that. > > The current build only use that for static build launcher, not custom launcher use libjli. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk/8241638.2/webrev/ > I think it would be simpler to drop the macros and have function prototypes in java_md_sollinux.h. That would avoid preprocessor code in the header file. The implementation in java_md_sollinux.c would then be simple #ifdef __solaris ... #else ... Minor nit is that the #include should probably be moved up to the top with the other includes. -Alan. From andy.herrick at oracle.com Tue Apr 7 12:11:28 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 7 Apr 2020 08:11:28 -0400 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> Message-ID: <661a1a37-ecea-86b9-a5b5-f8104c7ae69e@oracle.com> Alexander: Can I take it your OK with revising these tests in the followup CR ? /Andy On 4/4/20 8:53 AM, Andy Herrick wrote: > I think it best to modify these checks as part of a separate issue, > and leave these checks disabled as part of JDK-8237490.? I have filed > JDK-8242155 to enhance these tests, including restoring these checks. > > /ANdy > > On 4/3/2020 7:29 PM, Alexander Matveev wrote: >> Hi Andy, >> >> http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html >> >> Maybe better to check for Catalina case as well, instead of disabling >> check. We can assume that on Catalina code 3 and not notarized will >> consider as pass. In case if it fails for some other reasons. >> >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 4/3/20 7:20 AM, Andy Herrick wrote: >>> sorry missing webrev pointer [4] >>> >>> [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 >>> >>> /Andy >>> >>> On 4/3/2020 9:24 AM, Andy Herrick wrote: >>>> please review this revised webrev [4] to issue [2] >>>> >>>> The previous version generated a signed app that could be >>>> notarized, but then couldn't run because signing the whole app >>>> resigned the executable with reduced entitlements. >>>> >>>> This revision adds back in the entitlements when signing the whole >>>> app, as well as fixing the unit test that was failing the spctl >>>> call on Catalina due to signed app not being notarized. >>>> >>>> >>>> /Andy >>>> >>>> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>>>> revised with minor fixes as per below - webrev at [3] >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>>>> >>>>> /Andy >>>>> >>>>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>>>> >>>>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>>>> >>>>>>> Line 819,857,902 - Looks like temp debug log message. Remove it >>>>>>> or align with rest of code. >>>>>> I will fix this. >>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>>>> >>>>>>> Line 70 - Capital F. >>>>>> and this >>>>>>> >>>>>>> Since we added "--timestamp" and? "--options runtime" to >>>>>>> codesign, will it work with older Xcode and macOS we planning to >>>>>>> support? >>>>>> not sure - may need some discussion of what we support and >>>>>> possible conditional code here. >>>>>>> >>>>>>> Do we need any adjustments to signing tests we have? >>>>>> >>>>>> The existing tests pass, but this is not unexpected (and really >>>>>> means nothing) since the signing tests are all skipped unless >>>>>> specific test certs are installed on target machine. >>>>>> >>>>>> We need further discussion how one is expected to provision a >>>>>> machine to run these tests. >>>>>> >>>>>> /Andy >>>>>> >>>>>>> >>>>>>> Otherwise looks fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>>>> Please review the fix to issue [1] at [2]. >>>>>>>> >>>>>>>> This change enables notarization on Mac for dmg images and >>>>>>>> app-image zip files. >>>>>>>> >>>>>>>> /Andy >>>>>>>> >>>>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>>>> >>>>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>>>> >>>>>>> >> From david.holmes at oracle.com Tue Apr 7 12:50:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Apr 2020 22:50:51 +1000 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: References: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> Message-ID: <48fa1432-2931-bf03-5eb6-ef853950f98c@oracle.com> Hi Evgeny, On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: > Hi David, > >> I'm not at all sure this is generally what we want for every single >> test that uses ProcessTools! But I'm willing it to see it trialed. > > Well, it's mostly used for test VM runs. In runs I performed (artificial > "failures" included) the amounts of output were very small. > >> Please run full tier testing at least to tier 6 and ideally beyond >> before pushing this. There are potential implications for temporary >> (and more permanent) disk usage as well as additional time needed to >> write files out to disk. (Hopefully these are generally small enough >> that this doesn't make a noticeable difference.) > Done, thanks for suggestion. The additional runs showed no problems. Good to know - thanks. > I've provided Igor with a slightly modified version (Added notification > about the output file into the main test's log). Please review: > > http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ A couple of minor nits: 397 { why did you introduce a new block scope? 404 System.out.println(String.format( You can use printf rather than making a separate call to format. No need to see any update if you chose to make it. Thanks, David ----- > Best Regards, > > Evgeny. > > On 2020-04-02 02:07, David Holmes wrote: >> Thanks for sharing this Igor! >> >> I'm not at all sure this is generally what we want for every single >> test that uses ProcessTools! But I'm willing it to see it trialed. >> >> Evgeny: Please run full tier testing at least to tier 6 and ideally >> beyond before pushing this. There are potential implications for >> temporary (and more permanent) disk usage as well as additional time >> needed to write files out to disk. (Hopefully these are generally >> small enough that this doesn't make a noticeable difference.) >> >> Thanks, >> David >> >> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>> Hi Evgeny, >>> >>> (widening the audience, given this affects not just hotspot compiler, >>> but hotspot tests as well as core libs tests in general) >>> >>> overall that looks good to me. one suggestion, for the ease of >>> failure analysis it might be worth to print out the names of created >>> files, although this might potentially clutter the output, I don't >>> think it'll be a problem given we already print out things like >>> 'Gathering output for process ...' , 'Waiting for completion...' in >>> LazyOutputBuffer. >>> >>>> The change has been tested via a mach5 test runs (jdk-tier1 through >>>> 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, >>>> sparcv9). >>> this doesn't include any of hotspot tiers, could you please also run >>> hs-tier1--4? >>> // you can use tierN jobs which include both jdk and hs parts. >>> >>> Thanks, >>> -- Igor >>> >>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>> >>>> >>>> The bug had been created as a request to simplify investigation for >>>> compiler control tests failures. >>>> I found the functionality pretty generic and useful and made >>>> ProcessTools dump output as well as some diagnostic information for >>>> every executed process into a separate file. >>>> The diagnostic information contains cmdline, exit code, stdout and >>>> stderr. The output files are named like 'pid--output.log'. >>>> >>>> The change has been tested via a mach5 test runs (jdk-tier1 through >>>> 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, >>>> sparcv9). >>>> >>>> Please review, >>>> /Evgeny Nikitin. >>> From evgeny.nikitin at oracle.com Tue Apr 7 14:09:51 2020 From: evgeny.nikitin at oracle.com (Evgeny Nikitin) Date: Tue, 7 Apr 2020 16:09:51 +0200 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: <48fa1432-2931-bf03-5eb6-ef853950f98c@oracle.com> References: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> <48fa1432-2931-bf03-5eb6-ef853950f98c@oracle.com> Message-ID: <50f83e79-9273-fbaf-be6e-f4e0060e4fc7@oracle.com> Hi David, > why did you introduce a new block scope? To separate the action block from the other code. "A Poor/lazy man's method". I've preferred to lay it out this way because it makes the code more compact and easy to read (as opposing to looking for a only-once used method in some other part of the file) and due to the confusing name of OutputAnalyzer type (which I need as a storage for output, not as some analyzer). Creating a method with OutputAnalyzer as a parameter would make this method's purpose even more confusing. > You can use printf rather than making a separate call to format. Good point, I've missed that method. I'll fix it and ask Igor to change the webrev. Regards, Evgeny. On 2020-04-07 14:50, David Holmes wrote: > Hi Evgeny, > > On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: >> Hi David, >> >>> I'm not at all sure this is generally what we want for every single >>> test that uses ProcessTools! But I'm willing it to see it trialed. >> >> Well, it's mostly used for test VM runs. In runs I performed >> (artificial "failures" included) the amounts of output were very small. >> >>> Please run full tier testing at least to tier 6 and ideally beyond >>> before pushing this. There are potential implications for temporary >>> (and more permanent) disk usage as well as additional time needed to >>> write files out to disk. (Hopefully these are generally small enough >>> that this doesn't make a noticeable difference.) >> Done, thanks for suggestion. The additional runs showed no problems. > > Good to know - thanks. > >> I've provided Igor with a slightly modified version (Added >> notification about the output file into the main test's log). Please >> review: >> >> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ > > A couple of minor nits: > > ?397???????????? { > > why did you introduce a new block scope? > > ?404???????????????? System.out.println(String.format( > > You can use printf rather than making a separate call to format. > > No need to see any update if you chose to make it. > > Thanks, > David > ----- > >> Best Regards, >> >> Evgeny. >> >> On 2020-04-02 02:07, David Holmes wrote: >>> Thanks for sharing this Igor! >>> >>> I'm not at all sure this is generally what we want for every single >>> test that uses ProcessTools! But I'm willing it to see it trialed. >>> >>> Evgeny: Please run full tier testing at least to tier 6 and ideally >>> beyond before pushing this. There are potential implications for >>> temporary (and more permanent) disk usage as well as additional time >>> needed to write files out to disk. (Hopefully these are generally >>> small enough that this doesn't make a noticeable difference.) >>> >>> Thanks, >>> David >>> >>> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>>> Hi Evgeny, >>>> >>>> (widening the audience, given this affects not just hotspot >>>> compiler, but hotspot tests as well as core libs tests in general) >>>> >>>> overall that looks good to me. one suggestion, for the ease of >>>> failure analysis it might be worth to print out the names of >>>> created files, although this might potentially clutter the output, >>>> I don't think it'll be a problem given we already print out things >>>> like 'Gathering output for process ...' , 'Waiting for >>>> completion...' in LazyOutputBuffer. >>>> >>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>> macosx-x64, sparcv9). >>>> this doesn't include any of hotspot tiers, could you please also >>>> run hs-tier1--4? >>>> // you can use tierN jobs which include both jdk and hs parts. >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin >>>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>>> >>>>> >>>>> The bug had been created as a request to simplify investigation >>>>> for compiler control tests failures. >>>>> I found the functionality pretty generic and useful and made >>>>> ProcessTools dump output as well as some diagnostic information >>>>> for every executed process into a separate file. >>>>> The diagnostic information contains cmdline, exit code, stdout and >>>>> stderr. The output files are named like 'pid--output.log'. >>>>> >>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>> macosx-x64, sparcv9). >>>>> >>>>> Please review, >>>>> /Evgeny Nikitin. >>>> From pavel.rappo at oracle.com Tue Apr 7 15:28:26 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 7 Apr 2020 16:28:26 +0100 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> Message-ID: <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> Hi Ivan, > On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: > > Hi Pavel! > > A couple of comments. > > 1) > java/util/logging/Formatter.java > > This has one extra open curly brace: > > "{{@literal }" The leftmost curly brace is not a part of the "literal" inline tag, but rather a part of the message format string. Have a look at the method that the comment belongs to. Note what that method is looking for in a message string. > 2) > grep finds some more typos of the same kind that you've spotted. > > a) rgrep '^[ ]*\*'|grep ' ,'|less > > This find number of potential typos. For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma. A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. > > b) rgrep '^[ ]*\*'|grep '\w- '|less > > This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java > > (I only searched under src/java.base) Thanks. I've included some of those: true positive, non-controversial, and significant cases where I believe I sufficiently understood context. For instance, I was not sure if I reliably grasped the applicability of the "statically represented using varargs" phrase used widely across the VarHandle type. It looks like that phrase was blankedly added to @return and @return tags. So, I left it out for now. The updated patch can be found here: http://cr.openjdk.java.net/~prappo/8242230/webrev.01/ *** Some of the cases this patch addresses suggest that we might need to do something about how the Standard Doclet treats newline characters in source files. More often than not, newline characters are purely to control the width of the source lines. When carried over to the output, they may produce undesirable effects. Punctuation marks and contents of the Standard Doclet tags may be affected. That problem [1] is neither new nor trivial to address. Still, we should add something to the Standard Doclet Specification [2]. I'm not sure what we can do about it now other than work around the current behavior where it is significant. -Pavel P.S. CC'ing to javadoc-dev at openjdk.java.net ------------------------------------------------------------------------------- [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html > With kind regards, > > Ivan > > [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html > > [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html > > On 4/6/20 11:28 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: >> >> http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.text, >> java.util, >> java.util.logging, >> javax.lang.model.util, >> jdk.internal.reflect >> >> -Pavel >> > -- > With kind regards, > Ivan Gerasimov > From daniel.fuchs at oracle.com Tue Apr 7 16:00:04 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 Apr 2020 17:00:04 +0100 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> Message-ID: <794c504a-b847-be4f-0f87-12ab59ba18ee@oracle.com> Hi Ivan, On 07/04/2020 09:11, Ivan Gerasimov wrote: > 1) > java/util/logging/Formatter.java > > This has one extra open curly brace: > > "{{@literal }" > That one looks like a typo but is not a typo. It means: if the string contains "{0" or "{1" or ... cheers, -- daniel From jonathan.gibbons at oracle.com Tue Apr 7 16:10:08 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 7 Apr 2020 09:10:08 -0700 Subject: RFR 15 8225319: Remove the RMI static stub compiler rmic In-Reply-To: <61478f2a-b49e-757b-ce96-52d9da51344c@oracle.com> References: <61478f2a-b49e-757b-ce96-52d9da51344c@oracle.com> Message-ID: <3a5800ec-9a4c-41a5-5e63-323209cf09e8@oracle.com> The langtools test changes look OK. I investigated TestRecordTypes.java a bit because of the "jdk11" component in the file name, but the changes look OK, and there is caveat text in the test itself to indicate the file should be updated at some point to a more recent version anyway. -- Jon On 4/6/20 8:25 AM, Roger Riggs wrote: > Hi Amy, > > Thanks for looking in places I didn't grep for rmic references. > > Hotspot for cds and langtools for javadoc. > > The webrev is covers just the new changes but I will merge them before > the push. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc/ > > Thanks, Roger > > On 4/6/20 8:28 AM, Amy Lu wrote: >> Hi, Roger >> >> I noticed some other minor cleanup needed, will they be included in >> this fix, or separately in the future? >> >> 1. test/jdk/TEST.groups >> To remove `sun/tools/java` from core_tools and svc_tools group. (The >> only one test under `sun/tools/java` got removed in this patch.) >> >> 2. doc/building.md and doc/building.html, both mention rmic tool. >> >> 3. langtools tests >> module:jdk.rmic >> ./test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list >> ??????????????????? new String[] {"jdk.compiler", "jdk.rmic"}, >> ??????????????????? new String[] {"jdk.compiler", "jdk.javadoc", >> "jdk.rmic"}, >> ??????????????????? new String[] {"java.compiler", "jdk.compiler", >> "jdk.rmic"}, >> ??????????????????? new String[] {"java.compiler", "jdk.compiler", >> "jdk.javadoc", "jdk.rmic"}, >> ./test/langtools/tools/jdeps/modules/InverseDeps.java >> >> 4. hotspot tests >> ?* @summary run CTW for all classes from jdk.rmic module >> ?* @modules jdk.rmic >> ?* @run driver/timeout=7200 sun.hotspot.tools.ctw.CtwRunner >> modules:jdk.rmic >> ./test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java >> ???????????????????????? "sun/rmi/rmic/Main", >> ./test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java >> ??????? //???? sun.rmi.rmic.Main (testcase 4), >> ???????????? {"Loading non-shared app module class first", >> "sun.rmi.rmic", >> ????????????? "sun.rmi.rmic.RMIGenerator", "sun.rmi.rmic.Main"}, >> ./test/hotspot/jtreg/runtime/cds/appcds/test-classes/JimageClassPackage.java >> >> "sun/rmi/rmic/Main", >> ./test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java >> >> Thanks, >> Amy >> >> >> On 4/3/20 11:43 PM, Roger Riggs wrote: >>> Please review the CSR[1] and changes to remove the RMI static stub >>> compiler (rmic). >>> RMIC was deprecated for removal in JDK 13 [3]. >>> >>> The components modified are: >>> ?- remove the jdk.rmic module >>> ?- remove the jdk.rmic man page >>> ?- remove all tests of rmic or relying on rmic >>> ?- update or remove makefiles to remove references and dependencies >>> on rmic >>> ?- update source files in java.rmi module to remove extraneous >>> references to rmic >>> >>> Wevrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319 >>> >>> Thanks, Roger >>> >>> [1] CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8242049 >>> >>> [2] Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8225319 >>> >>> [3] Deprecate rmic for removal >>> https://bugs.openjdk.java.net/browse/JDK-8217412 >>> >> > From pavel.rappo at oracle.com Tue Apr 7 17:41:25 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 7 Apr 2020 18:41:25 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> Message-ID: <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. -Pavel [1] https://www.oracle.com/technetwork/community/oca-486395.html [2] changeset: 58344:65f30e209890 user: clanger date: Wed Mar 11 13:50:13 2020 +0100 files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java description: 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java Reviewed-by: clanger, vtewari Contributed-by: vipinsharma85 at gmail.com > On 6 Apr 2020, at 17:07, Vipin Sharma wrote: > > Hi David, > > I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net > Please suggest if there is any way I can create my user id to upload this patch. > > This is ~300 line patch file. > > Regards, > Vipin > >> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >> >> Hi Vipin, >> >> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>> Hi, >>> I have fixed a few warnings where the method parameter name is different in >>> code and Javadoc, need a sponsor for this patch. >>> Webrev is available at >>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >> >> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >> >> Thanks, >> David >> >>> Regards, >>> Vipin > From naoto.sato at oracle.com Tue Apr 7 17:52:17 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 7 Apr 2020 10:52:17 -0700 Subject: [15] RFR: 8242010: Upgrade IANA Language Subtag Registry to Version 2020-04-01 Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8242010 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8242010/webrev.00/ Besides the upgrade of the data file, I fixed the issue where EquivMapsGenerator had been ignoring "extlang" tag. Now it correctly maps the extlang, such as "zh-cmn" to its preferred language (in this case, "cmn") tag. Naoto From vipinsharma85 at gmail.com Tue Apr 7 18:50:52 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Wed, 8 Apr 2020 00:20:52 +0530 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> Message-ID: <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Hi Pavel, > On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: > > I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. Yes I have signed OCA. > > -Pavel > > [1] https://www.oracle.com/technetwork/community/oca-486395.html > [2] changeset: 58344:65f30e209890 > user: clanger > date: Wed Mar 11 13:50:13 2020 +0100 > files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java > description: > 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java > Reviewed-by: clanger, vtewari > Contributed-by: vipinsharma85 at gmail.com > Yes this is my first contribution. Patch text: --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 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 @@ -202,7 +202,7 @@ /** * Sets the padding mechanism of this cipher. * - * @param padding the padding mechanism + * @param paddingScheme the padding mechanism * * @exception NoSuchPaddingException if the requested padding mechanism * does not exist --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 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 @@ -313,10 +313,10 @@ * current Cipher.engineInit(...) implementation, * IllegalStateException will always be thrown upon invocation. * - * @param in the input buffer - * @param inOffset the offset in `in` where the input + * @param input the input buffer + * @param inputOffset the offset in `in` where the input * starts - * @param inLen the input length. + * @param inputLen the input length. * * @return n/a. * --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 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 @@ -130,7 +130,6 @@ * * @param plain the buffer with the input data to be encrypted * @param plainOffset the offset in `plain` - * @param plainLen the length of the input data * @param cipher the buffer for the result * @param cipherOffset the offset in `cipher` */ @@ -154,7 +153,6 @@ * * @param cipher the buffer with the input data to be decrypted * @param cipherOffset the offset in `cipherOffset` - * @param cipherLen the length of the input data * @param plain the buffer for the result * @param plainOffset the offset in `plain` */ --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 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 @@ -552,7 +552,6 @@ * * @param plain the buffer with the input data to be encrypted * @param plainOffset the offset in `plain` - * @param plainLen the length of the input data * @param cipher the buffer for the result * @param cipherOffset the offset in `cipher` * @@ -579,7 +578,6 @@ * * @param cipher the buffer with the input data to be decrypted * @param cipherOffset the offset in `cipherOffset` - * @param cipherLen the length of the input data * @param plain the buffer for the result * @param plainOffset the offset in `plain` * --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 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 @@ -262,8 +262,6 @@ * @param algorithm the algorithm name * @param key the key * @param iv the iv - * @param tagLenBytes the length of tag in bytes - * * @exception InvalidKeyException if the given key is inappropriate for * initializing this cipher */ --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 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 @@ -225,7 +225,7 @@ * * @param key the key * - * @param keySpec the requested format in which the key material shall be + * @param keySpecCl the requested format in which the key material shall be * returned * * @return the underlying key specification (key material) in the --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 @@ -92,7 +92,7 @@ * Sets the padding mechanism of this cipher. This algorithm only uses * PKCS #5 padding. * - * @param padding the padding mechanism + * @param paddingScheme the padding mechanism * * @exception NoSuchPaddingException if the requested padding mechanism * is invalid --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 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 @@ -75,7 +75,7 @@ * * @param key the key * - * @param keySpec the requested format in which the key material shall be + * @param keySpecCl the requested format in which the key material shall be * returned * * @return the underlying key specification (key material) in the --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 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 @@ -49,7 +49,7 @@ * interface. * * @param in the input buffer with the data to pad - * @param the offset in `in` where the padding bytes + * @param off the offset in `in` where the padding bytes * are appended * @param len the number of padding bytes to add * --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 @@ -1077,7 +1077,7 @@ * Start a new Process using an explicit array of redirects. * See {@link #start} for details of starting each Process. * - * @param redirect array of redirects for stdin, stdout, stderr + * @param redirects array of redirects for stdin, stdout, stderr * @return the new Process * @throws IOException if an I/O error occurs */ --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 @@ -731,7 +731,7 @@ * Constructs an empty GregorianCalendar. * * @param zone the given time zone - * @param aLocale the given locale + * @param locale the given locale * @param flag the flag requesting an empty instance */ GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 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 @@ -316,7 +316,7 @@ * If the address already has a scope-id or if the address is not local, ipv6 * or link local, then the original address is returned. * - * @param addr + * @param address * @exception SocketException if the given ipv6 link local address is found * on more than one local interface * @return --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 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 @@ -208,7 +208,7 @@ * Use New to get new HttpsClient. This constructor is meant to be * used only by New method. New properly checks for URL spoofing. * - * @param URL https URL with which a connection must be established + * @param url https URL with which a connection must be established */ private HttpsClient(SSLSocketFactory sf, URL url) throws IOException --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 @@ -321,7 +321,7 @@ /** * Loads the provider with the specified class name. * - * @param name the name of the provider + * @param pn the name of the provider * @return the Provider, or null if it cannot be found or loaded * @throws ProviderException all other exceptions are ignored */ --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2012, 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 @@ -72,7 +72,7 @@ * Constructor that initializes the input parameters. * * @param anchor the anchor selected to validate the target certificate - * @param testDate the time for which the validity of the certificate + * @param date the time for which the validity of the certificate * should be determined * @param sigProvider the name of the signature provider * @param sigOnly true if only signature checking is to be done; --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2018, 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 @@ -69,7 +69,7 @@ /** * Initialize the builder with the input parameters. * - * @param params the parameter set used to build a certification path + * @param buildParams the parameter set used to build a certification path */ Builder(BuilderParams buildParams) { this.buildParams = buildParams; --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 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 @@ -111,7 +111,7 @@ * @param ruleFile the name of the rule data file * @param ruleData the rule data loaded from the rule data file * @param dictionaryFile the name of the dictionary file - * @param dictionartData the dictionary data loaded from the dictionary file + * @param dictionaryData the dictionary data loaded from the dictionary file * @throws MissingResourceException if rule data or dictionary initialization failed */ public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, >> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >> >> Hi David, >> >> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >> Please suggest if there is any way I can create my user id to upload this patch. >> >> This is ~300 line patch file. >> >> Regards, >> Vipin >> >>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>> >>> Hi Vipin, >>> >>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>> Hi, >>>> I have fixed a few warnings where the method parameter name is different in >>>> code and Javadoc, need a sponsor for this patch. >>>> Webrev is available at >>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>> >>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>> >>> Thanks, >>> David >>> >>>> Regards, >>>> Vipin >> > Thanks, Vipin From rafael.wth at gmail.com Tue Apr 7 18:51:48 2020 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 7 Apr 2020 20:51:48 +0200 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References: <0aaaa441-c193-6155-4da3-5bd91888f73e@oracle.com> Message-ID: I created this webrev to also fix the second part that was previously fixed as part of 8202469: http://cr.openjdk.java.net/~winterhalter/8202473/webrev.00/ - this would be the second part of the adjustment. This is reported in https://bugs.openjdk.java.net/browse/JDK-8202473 and was closed as a duplicate. With this cleaner solution, the duplication does however no longer apply. Am Mo., 6. Apr. 2020 um 14:01 Uhr schrieb Joel Borggr?n-Franck < joel.borggren.franck at gmail.com>: > Many thanks to Vicente for sponsoring this. I'll start to look at the > second part shortly. > > cheers > /Joel > > On Mon, Mar 16, 2020 at 9:44 PM Joel Borggr?n-Franck < > joel.borggren.franck at gmail.com> wrote: > >> Looks good to me! >> >> I'll see if I can find a sponsor for this. >> >> cheers >> /Joel >> >> On Sat, Mar 7, 2020 at 2:15 AM Rafael Winterhalter >> wrote: >> >>> I finally found the time to look at this again, sorry for the delay. >>> >>> Thank you for your comments. I had the chance to better look into the >>> problem and simplify the code a bit more and also reduced the scope of the >>> fix to a single problem. I also added test cases that should be exhaustive >>> for all possible scenarios and adjusted the code comment. >>> >>> I uploaded the adjusted patch as a webrev: >>> http://cr.openjdk.java.net/~winterhalter/8202469/webrev.01/ >>> >>> Thanks, Rafael >>> >>> Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggr?n-Franck < >>> joel.borggren.franck at gmail.com>: >>> >>>> Hi Rafael, >>>> >>>> Thanks for reaching out and reminding me of this! >>>> >>>> I managed to find some time to look into 8202469 during the weekend. By >>>> swapping place of the TVars in the test I managed to isolate this without >>>> depending on 8202473, take a look at my hacky copy-paste update to your >>>> test at http://cr.openjdk.java.net/~jfranck/8202469/ . >>>> >>>> The comment on lines 269-276 needs to be updated. Perhaps include a >>>> table with the start index depending of the type? Also referencing JVMLS >>>> 4.4 for the structure of the bound might be instructive for future readers. >>>> >>>> My current understanding is that there are two problems with the code >>>> on (the original) lines 277-287: >>>> 1) Type Variables should have index 0 while getting index 1 due to >>>> lines 279-280. >>>> 2) Bounds that are instances of ParameterizedType always gets index 1 >>>> but if the first bound represents a Class type the index should be 0. >>>> >>>> Does this make sense? >>>> >>>> Can you make the if-switches positive? I find my original code with the >>>> negative tests hard to read and the update doesn't help. >>>> >>>> Also can you expand the test to cover the different kinds of bounds >>>> mentioned in 4.4 and also test Type Variables on methods, I suspect javac >>>> treats method (and constructor) tvars similarly but there have been bugs ... >>>> >>>> TL;DR please update the webrev with: >>>> >>>> - Split out test and fix for 8202469 >>>> - More test coverage of different kinds of bounds >>>> - Test for method tvars >>>> - See if you can rework the logic to have (mostly) positive tests in if >>>> switch >>>> >>>> Thanks again for looking into this, I'll start looking into 8202473, I >>>> think the fix for that one opens up a bigger rework of the code which is >>>> why I want to separate the two. >>>> >>>> cheers >>>> /Joel >>>> >>>> On Sun, Aug 4, 2019 at 10:12 PM Rafael Winterhalter < >>>> rafael.wth at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> appologies for the delay, I only managed to get my patched up to >>>>> webrev today (http://cr.openjdk.java.net/~winterhalter/). It's three >>>>> patches in total now, for the third one I could not add a test case, it >>>>> would require to compile an annotation property against an enumeration type >>>>> and load it against another class where the enumeration was turned into an >>>>> annotation. I struggled a bit with jtreg to make it work but I cannot see >>>>> myself complete this in a meaningful amount of time. However, I hope that >>>>> the patch and the error it solves are straightforward to see. >>>>> >>>>> I only submitted a patch for 8202469. 8202473 is solved by it. It's >>>>> two bugs but they are a symptom of the same oversight. >>>>> >>>>> I hope this helps you to review it but let me know if you have any >>>>> questions or if I should further adjust my patch. >>>>> >>>>> Best regards, Rafael >>>>> >>>>> Am Fr., 2. Aug. 2019 um 12:18 Uhr schrieb Rafael Winterhalter < >>>>> rafael.wth at gmail.com>: >>>>> >>>>>> Thanks Daniel, >>>>>> I did some work on Glassfish a bunch of years ago, I had no idea. >>>>>> I will try to split up the changes (I fixed another bug in annotation >>>>>> processing yesterday) and upload everything there. >>>>>> Best regards, Rafael >>>>>> >>>>>> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs < >>>>>> daniel.fuchs at oracle.com>: >>>>>> >>>>>>> Hi Rafael, >>>>>>> >>>>>>> On 02/08/2019 09:00, Joel Borggr?n-Franck wrote: >>>>>>> > I can host webrevs for you on cr to make it easier for other >>>>>>> reviewers, if >>>>>>> > you also send me the patches or webrefs off-list to get around the >>>>>>> > attachment stripping I can upload them to cr. >>>>>>> >>>>>>> I see that you are a JDK project author, so you already own a page >>>>>>> on cr (http://cr.openjdk.java.net/~winterhalter/) where you can >>>>>>> upload webrevs (e.g. using `scp` as in: >>>>>>> \$ scp -r webrev-NNNNN.01 winterhalter at cr.openjdk.java.net: ) >>>>>>> >>>>>>> best regards and welcome! >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>> From joe.darcy at oracle.com Tue Apr 7 19:23:36 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 7 Apr 2020 12:23:36 -0700 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> Message-ID: <7e4a3f58-3e6f-b1c6-7804-c0f178e2cc14@oracle.com> Hi Pavel, Looks fine in general, assuming the change to Class.java renders correctly in output. Thanks, -Joe On 4/7/2020 8:28 AM, Pavel Rappo wrote: > Hi Ivan, > >> On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: >> >> Hi Pavel! >> >> A couple of comments. >> >> 1) >> java/util/logging/Formatter.java >> >> This has one extra open curly brace: >> >> "{{@literal }" > The leftmost curly brace is not a part of the "literal" inline tag, but rather > a part of the message format string. Have a look at the method that the comment > belongs to. Note what that method is looking for in a message string. > >> 2) >> grep finds some more typos of the same kind that you've spotted. >> >> a) rgrep '^[ ]*\*'|grep ' ,'|less >> >> This find number of potential typos. For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma. A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. >> >> b) rgrep '^[ ]*\*'|grep '\w- '|less >> >> This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java >> >> (I only searched under src/java.base) > Thanks. I've included some of those: true positive, non-controversial, > and significant cases where I believe I sufficiently understood context. > > For instance, I was not sure if I reliably grasped the applicability of the > "statically represented using varargs" phrase used widely across the VarHandle > type. It looks like that phrase was blankedly added to @return and @return tags. > So, I left it out for now. > > The updated patch can be found here: > > http://cr.openjdk.java.net/~prappo/8242230/webrev.01/ > > *** > > Some of the cases this patch addresses suggest that we might need to do > something about how the Standard Doclet treats newline characters in source > files. More often than not, newline characters are purely to control the width > of the source lines. When carried over to the output, they may produce > undesirable effects. Punctuation marks and contents of the Standard Doclet tags > may be affected. > > That problem [1] is neither new nor trivial to address. Still, we should add > something to the Standard Doclet Specification [2]. > > I'm not sure what we can do about it now other than work around the current > behavior where it is significant. > > -Pavel > > P.S. CC'ing to javadoc-dev at openjdk.java.net > > ------------------------------------------------------------------------------- > [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap > [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html > >> With kind regards, >> >> Ivan >> >> [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html >> >> [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html >> >> On 4/6/20 11:28 AM, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: >>> >>> http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ >>> >>> This is a documentation cleanup. There are no code changes involved, >>> and the changes in documentation are mostly trivial. >>> >>> The following packages are affected: >>> >>> java.lang, >>> java.text, >>> java.util, >>> java.util.logging, >>> javax.lang.model.util, >>> jdk.internal.reflect >>> >>> -Pavel >>> >> -- >> With kind regards, >> Ivan Gerasimov >> From Roger.Riggs at oracle.com Tue Apr 7 19:47:01 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 7 Apr 2020 15:47:01 -0400 Subject: [15] RFR: 8242010: Upgrade IANA Language Subtag Registry to Version 2020-04-01 In-Reply-To: References: Message-ID: <25b581f2-a4b5-96a2-8e9f-af4f094f670b@oracle.com> Hi Naoto, Looks fine. In EquivMapsGenerator.java. typo: grandfahered -> grandfathered Thanks, Roger On 4/7/20 1:52 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8242010 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8242010/webrev.00/ > > Besides the upgrade of the data file, I fixed the issue where > EquivMapsGenerator had been ignoring "extlang" tag. Now it correctly > maps the extlang, such as "zh-cmn" to its preferred language (in this > case, "cmn") tag. > > Naoto From naoto.sato at oracle.com Tue Apr 7 19:48:59 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 7 Apr 2020 12:48:59 -0700 Subject: [15] RFR: 8242010: Upgrade IANA Language Subtag Registry to Version 2020-04-01 In-Reply-To: <25b581f2-a4b5-96a2-8e9f-af4f094f670b@oracle.com> References: <25b581f2-a4b5-96a2-8e9f-af4f094f670b@oracle.com> Message-ID: Thanks Roger. I will fix the typo before the push. Naoto On 4/7/20 12:47 PM, Roger Riggs wrote: > Hi Naoto, > > Looks fine. > > In EquivMapsGenerator.java. > typo: > > grandfahered -> grandfathered Thanks, Roger > > > > On 4/7/20 1:52 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8242010 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8242010/webrev.00/ >> >> Besides the upgrade of the data file, I fixed the issue where >> EquivMapsGenerator had been ignoring "extlang" tag. Now it correctly >> maps the extlang, such as "zh-cmn" to its preferred language (in this >> case, "cmn") tag. >> >> Naoto > From pavel.rappo at oracle.com Tue Apr 7 20:07:32 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 7 Apr 2020 21:07:32 +0100 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <7e4a3f58-3e6f-b1c6-7804-c0f178e2cc14@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> <7e4a3f58-3e6f-b1c6-7804-c0f178e2cc14@oracle.com> Message-ID: Thanks, Joe. I presume you mean me changing this * `@`{@code interface} to this * {@code @interface} Right? If so, then it renders the same way, and the `@interface` does not confuse the Standard Doclet. After JDK-8241780 "Allow \n@ inside inline tags" has been done and dusted we'll never have to think about that ever again. > On 7 Apr 2020, at 20:23, Joe Darcy wrote: > > Hi Pavel, > > Looks fine in general, assuming the change to Class.java renders correctly in output. > > Thanks, > > -Joe > > On 4/7/2020 8:28 AM, Pavel Rappo wrote: >> Hi Ivan, >> >>> On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: >>> >>> Hi Pavel! >>> >>> A couple of comments. >>> >>> 1) >>> java/util/logging/Formatter.java >>> >>> This has one extra open curly brace: >>> >>> "{{@literal }" >> The leftmost curly brace is not a part of the "literal" inline tag, but rather >> a part of the message format string. Have a look at the method that the comment >> belongs to. Note what that method is looking for in a message string. >> >>> 2) >>> grep finds some more typos of the same kind that you've spotted. >>> >>> a) rgrep '^[ ]*\*'|grep ' ,'|less >>> >>> This find number of potential typos. For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma. A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. >>> >>> b) rgrep '^[ ]*\*'|grep '\w- '|less >>> >>> This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java >>> >>> (I only searched under src/java.base) >> Thanks. I've included some of those: true positive, non-controversial, >> and significant cases where I believe I sufficiently understood context. >> >> For instance, I was not sure if I reliably grasped the applicability of the >> "statically represented using varargs" phrase used widely across the VarHandle >> type. It looks like that phrase was blankedly added to @return and @return tags. >> So, I left it out for now. >> >> The updated patch can be found here: >> >> http://cr.openjdk.java.net/~prappo/8242230/webrev.01/ >> >> *** >> >> Some of the cases this patch addresses suggest that we might need to do >> something about how the Standard Doclet treats newline characters in source >> files. More often than not, newline characters are purely to control the width >> of the source lines. When carried over to the output, they may produce >> undesirable effects. Punctuation marks and contents of the Standard Doclet tags >> may be affected. >> >> That problem [1] is neither new nor trivial to address. Still, we should add >> something to the Standard Doclet Specification [2]. >> >> I'm not sure what we can do about it now other than work around the current >> behavior where it is significant. >> >> -Pavel >> >> P.S. CC'ing to javadoc-dev at openjdk.java.net >> >> ------------------------------------------------------------------------------- >> [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap >> [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html >> >>> With kind regards, >>> >>> Ivan >>> >>> [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html >>> >>> [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html >>> >>> On 4/6/20 11:28 AM, Pavel Rappo wrote: >>>> Hello, >>>> >>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: >>>> >>>> http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ >>>> >>>> This is a documentation cleanup. There are no code changes involved, >>>> and the changes in documentation are mostly trivial. >>>> >>>> The following packages are affected: >>>> >>>> java.lang, >>>> java.text, >>>> java.util, >>>> java.util.logging, >>>> javax.lang.model.util, >>>> jdk.internal.reflect >>>> >>>> -Pavel >>>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> From joe.darcy at oracle.com Tue Apr 7 20:12:06 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 7 Apr 2020 13:12:06 -0700 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> <7e4a3f58-3e6f-b1c6-7804-c0f178e2cc14@oracle.com> Message-ID: <680e03e3-72dd-3c72-110f-79fe3f1f62a9@oracle.com> Hi Pavel, On 4/7/2020 1:07 PM, Pavel Rappo wrote: > Thanks, Joe. I presume you mean me changing this > > * `@`{@code interface} > > to this > > * {@code @interface} Correct. > > Right? If so, then it renders the same way, and the `@interface` does not > confuse the Standard Doclet. After JDK-8241780 "Allow \n@ inside inline tags" > has been done and dusted we'll never have to think about that ever again. I didn't double-check the history, but I may have added ??? `@`{@code interface} way back when and if note in this particular instance I recall that kind of javadoc contortion was necessary at the time to get (almost) the desired effect. Thanks, -Joe > >> On 7 Apr 2020, at 20:23, Joe Darcy wrote: >> >> Hi Pavel, >> >> Looks fine in general, assuming the change to Class.java renders correctly in output. >> >> Thanks, >> >> -Joe >> >> On 4/7/2020 8:28 AM, Pavel Rappo wrote: >>> Hi Ivan, >>> >>>> On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: >>>> >>>> Hi Pavel! >>>> >>>> A couple of comments. >>>> >>>> 1) >>>> java/util/logging/Formatter.java >>>> >>>> This has one extra open curly brace: >>>> >>>> "{{@literal }" >>> The leftmost curly brace is not a part of the "literal" inline tag, but rather >>> a part of the message format string. Have a look at the method that the comment >>> belongs to. Note what that method is looking for in a message string. >>> >>>> 2) >>>> grep finds some more typos of the same kind that you've spotted. >>>> >>>> a) rgrep '^[ ]*\*'|grep ' ,'|less >>>> >>>> This find number of potential typos. For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma. A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. >>>> >>>> b) rgrep '^[ ]*\*'|grep '\w- '|less >>>> >>>> This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java >>>> >>>> (I only searched under src/java.base) >>> Thanks. I've included some of those: true positive, non-controversial, >>> and significant cases where I believe I sufficiently understood context. >>> >>> For instance, I was not sure if I reliably grasped the applicability of the >>> "statically represented using varargs" phrase used widely across the VarHandle >>> type. It looks like that phrase was blankedly added to @return and @return tags. >>> So, I left it out for now. >>> >>> The updated patch can be found here: >>> >>> http://cr.openjdk.java.net/~prappo/8242230/webrev.01/ >>> >>> *** >>> >>> Some of the cases this patch addresses suggest that we might need to do >>> something about how the Standard Doclet treats newline characters in source >>> files. More often than not, newline characters are purely to control the width >>> of the source lines. When carried over to the output, they may produce >>> undesirable effects. Punctuation marks and contents of the Standard Doclet tags >>> may be affected. >>> >>> That problem [1] is neither new nor trivial to address. Still, we should add >>> something to the Standard Doclet Specification [2]. >>> >>> I'm not sure what we can do about it now other than work around the current >>> behavior where it is significant. >>> >>> -Pavel >>> >>> P.S. CC'ing to javadoc-dev at openjdk.java.net >>> >>> ------------------------------------------------------------------------------- >>> [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap >>> [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html >>> >>>> With kind regards, >>>> >>>> Ivan >>>> >>>> [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html >>>> >>>> [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html >>>> >>>> On 4/6/20 11:28 AM, Pavel Rappo wrote: >>>>> Hello, >>>>> >>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: >>>>> >>>>> http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ >>>>> >>>>> This is a documentation cleanup. There are no code changes involved, >>>>> and the changes in documentation are mostly trivial. >>>>> >>>>> The following packages are affected: >>>>> >>>>> java.lang, >>>>> java.text, >>>>> java.util, >>>>> java.util.logging, >>>>> javax.lang.model.util, >>>>> jdk.internal.reflect >>>>> >>>>> -Pavel >>>>> >>>> -- >>>> With kind regards, >>>> Ivan Gerasimov >>>> From ivan.gerasimov at oracle.com Tue Apr 7 21:12:24 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 7 Apr 2020 14:12:24 -0700 Subject: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting In-Reply-To: <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> References: <1933193D-859C-41EF-A576-1BFC826CFE2C@oracle.com> <848735ce-47a6-1eae-90ee-bd6618f98865@oracle.com> <97046552-B346-4856-813B-1058CDAE9EFE@oracle.com> Message-ID: Looks good to me, thanks! Kind regards, Ivan On 4/7/20 8:28 AM, Pavel Rappo wrote: > Hi Ivan, > >> On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote: >> >> Hi Pavel! >> >> A couple of comments. >> >> 1) >> java/util/logging/Formatter.java >> >> This has one extra open curly brace: >> >> "{{@literal }" > The leftmost curly brace is not a part of the "literal" inline tag, but rather > a part of the message format string. Have a look at the method that the comment > belongs to. Note what that method is looking for in a message string. > >> 2) >> grep finds some more typos of the same kind that you've spotted. >> >> a) rgrep '^[ ]*\*'|grep ' ,'|less >> >> This find number of potential typos. For example, the javadoc for VarHandle [1] has 53 occurrances of space-before-comma. A few more are found in j.l.Thread, j.io.DataOutput, j.l.String, etc. >> >> b) rgrep '^[ ]*\*'|grep '\w- '|less >> >> This find the word 'network' broken with a hyphen at [2] and also in share/classes/sun/net/util/IPAddressUtil.java >> >> (I only searched under src/java.base) > Thanks. I've included some of those: true positive, non-controversial, > and significant cases where I believe I sufficiently understood context. > > For instance, I was not sure if I reliably grasped the applicability of the > "statically represented using varargs" phrase used widely across the VarHandle > type. It looks like that phrase was blankedly added to @return and @return tags. > So, I left it out for now. > > The updated patch can be found here: > > http://cr.openjdk.java.net/~prappo/8242230/webrev.01/ > > *** > > Some of the cases this patch addresses suggest that we might need to do > something about how the Standard Doclet treats newline characters in source > files. More often than not, newline characters are purely to control the width > of the source lines. When carried over to the output, they may produce > undesirable effects. Punctuation marks and contents of the Standard Doclet tags > may be affected. > > That problem [1] is neither new nor trivial to address. Still, we should add > something to the Standard Doclet Specification [2]. > > I'm not sure what we can do about it now other than work around the current > behavior where it is significant. > > -Pavel > > P.S. CC'ing to javadoc-dev at openjdk.java.net > > ------------------------------------------------------------------------------- > [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap > [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html > >> With kind regards, >> >> Ivan >> >> [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/VarHandle.html >> >> [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/Inet4Address.html >> >> On 4/6/20 11:28 AM, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: >>> >>> http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ >>> >>> This is a documentation cleanup. There are no code changes involved, >>> and the changes in documentation are mostly trivial. >>> >>> The following packages are affected: >>> >>> java.lang, >>> java.text, >>> java.util, >>> java.util.logging, >>> javax.lang.model.util, >>> jdk.internal.reflect >>> >>> -Pavel >>> >> -- >> With kind regards, >> Ivan Gerasimov >> -- With kind regards, Ivan Gerasimov From mark.reinhold at oracle.com Tue Apr 7 21:39:13 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 07 Apr 2020 14:39:13 -0700 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: <20200402141254.742895118@eggemoggin.niobe.net> Message-ID: <20200407143913.532190959@eggemoggin.niobe.net> 2020/4/3 6:36:53 -0700, christoph.langer at sap.com: > 2020/4/2 14:12:54 -0700, mark.reinhold at oracle.com: >> I thought about doing this when I originally wrote that plugin, but it?s >> so awkward to achieve with ASM -- as demonstrated by your patch -- that >> I concluded it wasn?t worth it. Who will notice an extra pop in a basic >> block that?s only ever executed once? Is the complexity of this new >> code worth the benefit? > > Well, first I started playing with this and got a bit obsessed to find > optimizations in that area. (I learned quite a bit about java asm.) > It would be of higher (micro-)benefit for common VM startup if the > fields to be modified could be final but that's even more awkward to > do and requires intricate knowledge and assumptions about how > VersionProps.java is structured. So I decided against messing with > that. > > Eventually I came up with this result and then I also asked myself the > question whether the new complexity was worth the benefit. I answered > myself with a yes (though definitely not a clear one ??), and that's > why I proposed the change. After all, the new complexity isn't huge... > > So, would that be your terminal veto or could you imagine accepting > the change? I won?t veto it. - Mark From alexander.matveev at oracle.com Tue Apr 7 21:57:52 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Tue, 7 Apr 2020 14:57:52 -0700 Subject: RFR: JDK-8237490: [macos] Add support notarizing jpackage app-image and dmg In-Reply-To: <661a1a37-ecea-86b9-a5b5-f8104c7ae69e@oracle.com> References: <5cffb6fe-1a79-ee87-eed0-040f44d850e9@oracle.com> <12b65308-596f-cb17-3afa-db771a048dcb@oracle.com> <2c54a3a3-4d63-e232-9a6a-8a91895e9ade@oracle.com> <03eb7373-5699-26e7-0432-170fe1f6e536@oracle.com> <86f600ed-d338-a47e-7e32-df8c27be488e@oracle.com> <24f17fb9-c948-1d92-c8bd-935f96ae481f@oracle.com> <661a1a37-ecea-86b9-a5b5-f8104c7ae69e@oracle.com> Message-ID: Hi Andy, Yes, it is fine to fix test in followup CR. Thanks, Alexander On 4/7/20 5:11 AM, Andy Herrick wrote: > Alexander: > > Can I take it your OK with revising these tests in the followup CR ? > > /Andy > > On 4/4/20 8:53 AM, Andy Herrick wrote: >> I think it best to modify these checks as part of a separate issue, >> and leave these checks disabled as part of JDK-8237490.? I have filed >> JDK-8242155 to enhance these tests, including restoring these checks. >> >> /ANdy >> >> On 4/3/2020 7:29 PM, Alexander Matveev wrote: >>> Hi Andy, >>> >>> http://cr.openjdk.java.net/~herrick/8237490/webrev.07/test/jdk/tools/jpackage/macosx/base/SigningBase.java.frames.html >>> >>> Maybe better to check for Catalina case as well, instead of >>> disabling check. We can assume that on Catalina code 3 and not >>> notarized will consider as pass. In case if it fails for some other >>> reasons. >>> >>> Otherwise looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 4/3/20 7:20 AM, Andy Herrick wrote: >>>> sorry missing webrev pointer [4] >>>> >>>> [4] - http://cr.openjdk.java.net/~herrick/8237490/webrev.07 >>>> >>>> /Andy >>>> >>>> On 4/3/2020 9:24 AM, Andy Herrick wrote: >>>>> please review this revised webrev [4] to issue [2] >>>>> >>>>> The previous version generated a signed app that could be >>>>> notarized, but then couldn't run because signing the whole app >>>>> resigned the executable with reduced entitlements. >>>>> >>>>> This revision adds back in the entitlements when signing the whole >>>>> app, as well as fixing the unit test that was failing the spctl >>>>> call on Catalina due to signed app not being notarized. >>>>> >>>>> >>>>> /Andy >>>>> >>>>> On 3/30/2020 1:19 PM, Andy Herrick wrote: >>>>>> revised with minor fixes as per below - webrev at [3] >>>>>> >>>>>> [3] http://cr.openjdk.java.net/~herrick/8237490/webrev.06/ >>>>>> >>>>>> /Andy >>>>>> >>>>>> On 3/28/2020 9:43 AM, Andy Herrick wrote: >>>>>>> >>>>>>> On 3/27/2020 5:18 PM, Alexander Matveev wrote: >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/MacAppImageBuilder.java.frames.html >>>>>>>> >>>>>>>> Line 819,857,902 - Looks like temp debug log message. Remove it >>>>>>>> or align with rest of code. >>>>>>> I will fix this. >>>>>>>> http://cr.openjdk.java.net/~herrick/8237490/webrev.05/src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal/resources/MacResources.properties.frames.html >>>>>>>> >>>>>>>> Line 70 - Capital F. >>>>>>> and this >>>>>>>> >>>>>>>> Since we added "--timestamp" and? "--options runtime" to >>>>>>>> codesign, will it work with older Xcode and macOS we planning >>>>>>>> to support? >>>>>>> not sure - may need some discussion of what we support and >>>>>>> possible conditional code here. >>>>>>>> >>>>>>>> Do we need any adjustments to signing tests we have? >>>>>>> >>>>>>> The existing tests pass, but this is not unexpected (and really >>>>>>> means nothing) since the signing tests are all skipped unless >>>>>>> specific test certs are installed on target machine. >>>>>>> >>>>>>> We need further discussion how one is expected to provision a >>>>>>> machine to run these tests. >>>>>>> >>>>>>> /Andy >>>>>>> >>>>>>>> >>>>>>>> Otherwise looks fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>>> On 3/27/20 12:35 PM, Andy Herrick wrote: >>>>>>>>> Please review the fix to issue [1] at [2]. >>>>>>>>> >>>>>>>>> This change enables notarization on Mac for dmg images and >>>>>>>>> app-image zip files. >>>>>>>>> >>>>>>>>> /Andy >>>>>>>>> >>>>>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8237490 >>>>>>>>> >>>>>>>>> [2]: http://cr.openjdk.java.net/~herrick/8237490 >>>>>>>>> >>>>>>>> >>> From claes.redestad at oracle.com Tue Apr 7 22:11:57 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 8 Apr 2020 00:11:57 +0200 Subject: RFR: 8242039: Improve jlink VersionPropsPlugin In-Reply-To: References: <20200402141254.742895118@eggemoggin.niobe.net> Message-ID: On 2020-04-03 15:36, Langer, Christoph wrote: > Eventually I came up with this result and then I also asked myself the question whether the new complexity was worth the benefit. I answered myself with a yes (though definitely not a clear one ??), and that's why I proposed the change. After all, the new complexity isn't huge... I don't mind the cleaned up patch[1]. It also gets rid of the constants being replaced, which I assume will otherwise be loaded and kept on the heap and in the string table forever. While unlikely to cause confusion, I'd argue that not finding the value replaced in heap dumps might be of some value. /Claes [1] http://cr.openjdk.java.net/~clanger/webrevs/8242039.1/ From kim.barrett at oracle.com Wed Apr 8 00:25:44 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Apr 2020 20:25:44 -0400 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate Message-ID: [Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. This function is needed to test the referent of a Reference object without artificially extending the lifetime of the referent object, as may happen when calling Reference.get. Some garbage collectors require extending the lifetime of a weak referent when accessed, in order to maintain collector invariants. Lifetime extension may occur with any collector when the Reference is a SoftReference, as calling get indicates recent access. This new function also allows testing the referent of a PhantomReference, which can't be accessed by calling get. The new function uses a native method whose implementation is in the VM so it can use the Access API. It is the intent that this function will be intrinsified by optimizing compilers like C2 or graal, but that hasn't been implemented yet. Bear that in mind before rushing off to change existing uses of Reference.get. CR: https://bugs.openjdk.java.net/browse/JDK-8188055 https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) Webrev: https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ Testing: mach5 tier1 Locally (linux-x64) verified the new test passes with various garbage collectors. From huizhe.wang at oracle.com Wed Apr 8 01:23:11 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 7 Apr 2020 18:23:11 -0700 Subject: [15] RFR: 8242010: Upgrade IANA Language Subtag Registry to Version 2020-04-01 In-Reply-To: References: <25b581f2-a4b5-96a2-8e9f-af4f094f670b@oracle.com> Message-ID: <48547e5e-c6ce-b91e-bf3e-00ea4df08e48@oracle.com> +1 Best, Joe On 4/7/20 12:48 PM, naoto.sato at oracle.com wrote: > Thanks Roger. I will fix the typo before the push. > > Naoto > > On 4/7/20 12:47 PM, Roger Riggs wrote: >> Hi Naoto, >> >> Looks fine. >> >> In EquivMapsGenerator.java. >> typo: >> >> grandfahered -> grandfathered Thanks, Roger >> >> >> >> On 4/7/20 1:52 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242010 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8242010/webrev.00/ >>> >>> Besides the upgrade of the data file, I fixed the issue where >>> EquivMapsGenerator had been ignoring "extlang" tag. Now it correctly >>> maps the extlang, such as "zh-cmn" to its preferred language (in >>> this case, "cmn") tag. >>> >>> Naoto >> From per.liden at oracle.com Wed Apr 8 07:32:11 2020 From: per.liden at oracle.com (Per Liden) Date: Wed, 8 Apr 2020 09:32:11 +0200 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: <1fb33e51-9ed4-23d5-22f8-334e5e6f6c7e@oracle.com> Hi Kim, On 4/8/20 2:25 AM, Kim Barrett wrote: > [Note review on both core-libs and hotspot-gc-dev lists; try not to lose > either when replying.] > > Please review a new function: java.lang.ref.Reference.refersTo. Nice! > > This function is needed to test the referent of a Reference object > without artificially extending the lifetime of the referent object, as > may happen when calling Reference.get. Some garbage collectors > require extending the lifetime of a weak referent when accessed, in > order to maintain collector invariants. Lifetime extension may occur > with any collector when the Reference is a SoftReference, as calling > get indicates recent access. This new function also allows testing > the referent of a PhantomReference, which can't be accessed by calling > get. > > The new function uses a native method whose implementation is in the > VM so it can use the Access API. It is the intent that this function > will be intrinsified by optimizing compilers like C2 or graal, but > that hasn't been implemented yet. Bear that in mind before rushing > off to change existing uses of Reference.get. Do we have an enhancement filed for this? We should make it very clear that such an intrinsic is not allowed to safepoint between loading the referent and comparing it. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188055 > https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ The patch looks good to me, just two minor comments: java/lang/ref/Reference.java ---------------------------- 349 * @param obj is the object to compare with the referenced object, or 350 * {@code null}. May I suggest "referenced object" -> "referent" to keep the nomenclature intact. gc/TestReferenceRefersTo.java ----------------------------- 208 long timeout = 1000; 209 while (true) { 210 Reference ref = queue.remove(timeout); 211 if (ref == null) { 212 break; 213 } else if (ref == testPhantom1) { 214 testPhantom1 = null; 215 } else if (ref == testWeak2) { 216 testWeak2 = null; 217 } else if (ref == testWeak3) { 218 testWeak3 = null; 219 } else if (ref == testWeak4) { 220 testWeak4 = null; 221 } else { 222 fail("unexpected reference in queue"); 223 } 224 } That timeout look unnecessarily short, and I imagine it could cause intermittent failures on really slow machines. I would suggest we make that more like 60 seconds, alternatively skip the timeout all together and let the whole test timeout if the expected references don't appear in the queue. cheers, Per > > Testing: > mach5 tier1 > > Locally (linux-x64) verified the new test passes with various garbage > collectors. > From thomas.schatzl at oracle.com Wed Apr 8 08:11:18 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 8 Apr 2020 10:11:18 +0200 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: <004f118b-80a3-b7bd-2c77-3053f7e2de21@oracle.com> Hi, On 08.04.20 02:25, Kim Barrett wrote: > [Note review on both core-libs and hotspot-gc-dev lists; try not to lose > either when replying.] > > Please review a new function: java.lang.ref.Reference.refersTo. > [...] > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188055 > https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ > > Testing: > mach5 tier1 > > Locally (linux-x64) verified the new test passes with various garbage > collectors. > Lgtm. Thomas From kim.barrett at oracle.com Wed Apr 8 08:37:56 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Apr 2020 04:37:56 -0400 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: <004f118b-80a3-b7bd-2c77-3053f7e2de21@oracle.com> References: <004f118b-80a3-b7bd-2c77-3053f7e2de21@oracle.com> Message-ID: <95BA24BA-D8D8-4FB7-A92B-4B8A5A6D5478@oracle.com> > On Apr 8, 2020, at 4:11 AM, Thomas Schatzl wrote: > > Hi, > > On 08.04.20 02:25, Kim Barrett wrote: >> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >> either when replying.] >> Please review a new function: java.lang.ref.Reference.refersTo. > [...] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8188055 >> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >> Testing: >> mach5 tier1 >> Locally (linux-x64) verified the new test passes with various garbage >> collectors. > > Lgtm. > > Thomas Thanks. From david.holmes at oracle.com Wed Apr 8 09:27:23 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Apr 2020 19:27:23 +1000 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: <8f0baa70-0bc3-caa7-13eb-364c45a466d6@oracle.com> Hi Kim, On 8/04/2020 10:25 am, Kim Barrett wrote: > [Note review on both core-libs and hotspot-gc-dev lists; try not to lose > either when replying.] > > Please review a new function: java.lang.ref.Reference.refersTo. > > This function is needed to test the referent of a Reference object > without artificially extending the lifetime of the referent object, as > may happen when calling Reference.get. Some garbage collectors > require extending the lifetime of a weak referent when accessed, in > order to maintain collector invariants. Lifetime extension may occur > with any collector when the Reference is a SoftReference, as calling > get indicates recent access. This new function also allows testing > the referent of a PhantomReference, which can't be accessed by calling > get. This causes a slight conflict with the documentation for get() which states: "Because the referent of a phantom reference is always inaccessible ..." when the new method obviously accesses it. > > The new function uses a native method whose implementation is in the > VM so it can use the Access API. It is the intent that this function > will be intrinsified by optimizing compilers like C2 or graal, but > that hasn't been implemented yet. Bear that in mind before rushing > off to change existing uses of Reference.get. I assume such intrinsification is intended for JDK 15 as well though, as end users may well rush to change their code! > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188055 > https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) In the specification: * @param obj is the object to compare with the referenced object, or * {@code null}. First delete "is", the commone style for @param is just to say "the xxx" or "a yyy". Second I suggest: s/the referenced object/this reference object's referent/ In the apinote: * collection cycle. {@link #refersTo(Object) refersTo} can be used to I suggest: * collection cycle. The {@link #refersTo(Object) refersTo} method can be used to so we don't start a sentence with a lower-case code-font word. Also a query in the apinote: * This method returns a strong reference to the referent. This may cause * the garbage collector to treat it as strongly reachable until some later Surely if the method returns a strong reference then the GC _will_ treat it as strongly reachable, not "may" ? > Webrev: > https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ Code changes look good. No comment on the test - I'll leave it to others to analyse that. Thanks, David ----- > Testing: > mach5 tier1 > > Locally (linux-x64) verified the new test passes with various garbage > collectors. > From shade at redhat.com Wed Apr 8 09:44:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 11:44:10 +0200 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: On 4/8/20 2:25 AM, Kim Barrett wrote: > Webrev: > https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ src/hotspot/share/prims/jvm.cpp: *) Do we really need a typedef (L3250) for something that is used once at L3253? 3248 JVM_ENTRY(jboolean, JVM_ReferenceRefersTo(JNIEnv* env, jobject ref, jobject o)) 3249 JVMWrapper("JVM_ReferenceRefersTo"); 3250 typedef HeapAccess ReferentAccess; 3251 const int referent_offset = java_lang_ref_Reference::referent_offset; 3252 oop ref_oop = JNIHandles::resolve_non_null(ref); 3253 oop referent = ReferentAccess::oop_load_at(ref_oop, referent_offset); 3254 return referent == JNIHandles::resolve(o); 3255 JVM_END *) Double new-line: 3256 3257 test/hotspot/jtreg/gc/TestReferenceRefersTo.java: *) Typo, "unex[p]ected": 134 fail(which + " refers to unexected value"); Otherwise seems fine. -- Thanks, -Aleksey From pavel.rappo at oracle.com Wed Apr 8 11:50:33 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 8 Apr 2020 12:50:33 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: Vipin, here you go: https://bugs.openjdk.java.net/browse/JDK-8242366 http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ I took the liberty of additionally fixing a couple of parameters' names, a typo, and `@exception` tags for checked exceptions that were neither thrown nor imported. The bulk of the change is in Security. Some changes are in Networking. The appropriate mailing lists are in CC for this email. We should wait for their feedback. Changes in core area look good to me and I'd be surprised if there are any problems with the remaining portion of the changeset. -Pavel > On 7 Apr 2020, at 19:50, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >> >> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. > Yes I have signed OCA. >> >> -Pavel >> >> [1] https://www.oracle.com/technetwork/community/oca-486395.html >> [2] changeset: 58344:65f30e209890 >> user: clanger >> date: Wed Mar 11 13:50:13 2020 +0100 >> files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java >> description: >> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java >> Reviewed-by: clanger, vtewari >> Contributed-by: vipinsharma85 at gmail.com >> > Yes this is my first contribution. > > Patch text: > > --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2002, 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 > @@ -202,7 +202,7 @@ > /** > * Sets the padding mechanism of this cipher. > * > - * @param padding the padding mechanism > + * @param paddingScheme the padding mechanism > * > * @exception NoSuchPaddingException if the requested padding mechanism > * does not exist > --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 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 > @@ -313,10 +313,10 @@ > * current Cipher.engineInit(...) implementation, > * IllegalStateException will always be thrown upon invocation. > * > - * @param in the input buffer > - * @param inOffset the offset in `in` where the input > + * @param input the input buffer > + * @param inputOffset the offset in `in` where the input > * starts > - * @param inLen the input length. > + * @param inputLen the input length. > * > * @return n/a. > * > --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 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 > @@ -130,7 +130,6 @@ > * > * @param plain the buffer with the input data to be encrypted > * @param plainOffset the offset in `plain` > - * @param plainLen the length of the input data > * @param cipher the buffer for the result > * @param cipherOffset the offset in `cipher` > */ > @@ -154,7 +153,6 @@ > * > * @param cipher the buffer with the input data to be decrypted > * @param cipherOffset the offset in `cipherOffset` > - * @param cipherLen the length of the input data > * @param plain the buffer for the result > * @param plainOffset the offset in `plain` > */ > --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 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 > @@ -552,7 +552,6 @@ > * > * @param plain the buffer with the input data to be encrypted > * @param plainOffset the offset in `plain` > - * @param plainLen the length of the input data > * @param cipher the buffer for the result > * @param cipherOffset the offset in `cipher` > * > @@ -579,7 +578,6 @@ > * > * @param cipher the buffer with the input data to be decrypted > * @param cipherOffset the offset in `cipherOffset` > - * @param cipherLen the length of the input data > * @param plain the buffer for the result > * @param plainOffset the offset in `plain` > * > --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 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 > @@ -262,8 +262,6 @@ > * @param algorithm the algorithm name > * @param key the key > * @param iv the iv > - * @param tagLenBytes the length of tag in bytes > - * > * @exception InvalidKeyException if the given key is inappropriate for > * initializing this cipher > */ > --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 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 > @@ -225,7 +225,7 @@ > * > * @param key the key > * > - * @param keySpec the requested format in which the key material shall be > + * @param keySpecCl the requested format in which the key material shall be > * returned > * > * @return the underlying key specification (key material) in the > --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 > @@ -92,7 +92,7 @@ > * Sets the padding mechanism of this cipher. This algorithm only uses > * PKCS #5 padding. > * > - * @param padding the padding mechanism > + * @param paddingScheme the padding mechanism > * > * @exception NoSuchPaddingException if the requested padding mechanism > * is invalid > --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 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 > @@ -75,7 +75,7 @@ > * > * @param key the key > * > - * @param keySpec the requested format in which the key material shall be > + * @param keySpecCl the requested format in which the key material shall be > * returned > * > * @return the underlying key specification (key material) in the > --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 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 > @@ -49,7 +49,7 @@ > * interface. > * > * @param in the input buffer with the data to pad > - * @param the offset in `in` where the padding bytes > + * @param off the offset in `in` where the padding bytes > * are appended > * @param len the number of padding bytes to add > * > --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 > +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 > @@ -1077,7 +1077,7 @@ > * Start a new Process using an explicit array of redirects. > * See {@link #start} for details of starting each Process. > * > - * @param redirect array of redirects for stdin, stdout, stderr > + * @param redirects array of redirects for stdin, stdout, stderr > * @return the new Process > * @throws IOException if an I/O error occurs > */ > --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 > +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 > @@ -731,7 +731,7 @@ > * Constructs an empty GregorianCalendar. > * > * @param zone the given time zone > - * @param aLocale the given locale > + * @param locale the given locale > * @param flag the flag requesting an empty instance > */ > GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { > --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 > +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 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 > @@ -316,7 +316,7 @@ > * If the address already has a scope-id or if the address is not local, ipv6 > * or link local, then the original address is returned. > * > - * @param addr > + * @param address > * @exception SocketException if the given ipv6 link local address is found > * on more than one local interface > * @return > --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 > +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 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 > @@ -208,7 +208,7 @@ > * Use New to get new HttpsClient. This constructor is meant to be > * used only by New method. New properly checks for URL spoofing. > * > - * @param URL https URL with which a connection must be established > + * @param url https URL with which a connection must be established > */ > private HttpsClient(SSLSocketFactory sf, URL url) > throws IOException > --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 > +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 > @@ -321,7 +321,7 @@ > /** > * Loads the provider with the specified class name. > * > - * @param name the name of the provider > + * @param pn the name of the provider > * @return the Provider, or null if it cannot be found or loaded > * @throws ProviderException all other exceptions are ignored > */ > --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 > +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2012, 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 > @@ -72,7 +72,7 @@ > * Constructor that initializes the input parameters. > * > * @param anchor the anchor selected to validate the target certificate > - * @param testDate the time for which the validity of the certificate > + * @param date the time for which the validity of the certificate > * should be determined > * @param sigProvider the name of the signature provider > * @param sigOnly true if only signature checking is to be done; > --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 > +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2018, 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 > @@ -69,7 +69,7 @@ > /** > * Initialize the builder with the input parameters. > * > - * @param params the parameter set used to build a certification path > + * @param buildParams the parameter set used to build a certification path > */ > Builder(BuilderParams buildParams) { > this.buildParams = buildParams; > --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 > +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 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 > @@ -111,7 +111,7 @@ > * @param ruleFile the name of the rule data file > * @param ruleData the rule data loaded from the rule data file > * @param dictionaryFile the name of the dictionary file > - * @param dictionartData the dictionary data loaded from the dictionary file > + * @param dictionaryData the dictionary data loaded from the dictionary file > * @throws MissingResourceException if rule data or dictionary initialization failed > */ > public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, > > >>> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >>> >>> Hi David, >>> >>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >>> Please suggest if there is any way I can create my user id to upload this patch. >>> >>> This is ~300 line patch file. >>> >>> Regards, >>> Vipin >>> >>>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>>> >>>> Hi Vipin, >>>> >>>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>>> Hi, >>>>> I have fixed a few warnings where the method parameter name is different in >>>>> code and Javadoc, need a sponsor for this patch. >>>>> Webrev is available at >>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>>> >>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards, >>>>> Vipin >>> >> > Thanks, > Vipin From david.holmes at oracle.com Wed Apr 8 12:56:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Apr 2020 22:56:06 +1000 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: Hi Pavel, Not a review ... On 8/04/2020 9:50 pm, Pavel Rappo wrote: > Vipin, here you go: > > https://bugs.openjdk.java.net/browse/JDK-8242366 > http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ > > I took the liberty of additionally fixing a couple of parameters' names, > a typo, and `@exception` tags for checked exceptions that were neither thrown > nor imported. While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.) Cheers, David > The bulk of the change is in Security. Some changes are in Networking. The > appropriate mailing lists are in CC for this email. We should wait for their > feedback. > > Changes in core area look good to me and I'd be surprised if there are any > problems with the remaining portion of the changeset. > > -Pavel > >> On 7 Apr 2020, at 19:50, Vipin Sharma wrote: >> >> Hi Pavel, >> >>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >>> >>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. >> Yes I have signed OCA. >>> >>> -Pavel >>> >>> [1] https://www.oracle.com/technetwork/community/oca-486395.html >>> [2] changeset: 58344:65f30e209890 >>> user: clanger >>> date: Wed Mar 11 13:50:13 2020 +0100 >>> files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java >>> description: >>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java >>> Reviewed-by: clanger, vtewari >>> Contributed-by: vipinsharma85 at gmail.com >>> >> Yes this is my first contribution. >> >> Patch text: >> >> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2002, 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 >> @@ -202,7 +202,7 @@ >> /** >> * Sets the padding mechanism of this cipher. >> * >> - * @param padding the padding mechanism >> + * @param paddingScheme the padding mechanism >> * >> * @exception NoSuchPaddingException if the requested padding mechanism >> * does not exist >> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 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 >> @@ -313,10 +313,10 @@ >> * current Cipher.engineInit(...) implementation, >> * IllegalStateException will always be thrown upon invocation. >> * >> - * @param in the input buffer >> - * @param inOffset the offset in `in` where the input >> + * @param input the input buffer >> + * @param inputOffset the offset in `in` where the input >> * starts >> - * @param inLen the input length. >> + * @param inputLen the input length. >> * >> * @return n/a. >> * >> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1998, 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 >> @@ -130,7 +130,6 @@ >> * >> * @param plain the buffer with the input data to be encrypted >> * @param plainOffset the offset in `plain` >> - * @param plainLen the length of the input data >> * @param cipher the buffer for the result >> * @param cipherOffset the offset in `cipher` >> */ >> @@ -154,7 +153,6 @@ >> * >> * @param cipher the buffer with the input data to be decrypted >> * @param cipherOffset the offset in `cipherOffset` >> - * @param cipherLen the length of the input data >> * @param plain the buffer for the result >> * @param plainOffset the offset in `plain` >> */ >> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -552,7 +552,6 @@ >> * >> * @param plain the buffer with the input data to be encrypted >> * @param plainOffset the offset in `plain` >> - * @param plainLen the length of the input data >> * @param cipher the buffer for the result >> * @param cipherOffset the offset in `cipher` >> * >> @@ -579,7 +578,6 @@ >> * >> * @param cipher the buffer with the input data to be decrypted >> * @param cipherOffset the offset in `cipherOffset` >> - * @param cipherLen the length of the input data >> * @param plain the buffer for the result >> * @param plainOffset the offset in `plain` >> * >> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2013, 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 >> @@ -262,8 +262,6 @@ >> * @param algorithm the algorithm name >> * @param key the key >> * @param iv the iv >> - * @param tagLenBytes the length of tag in bytes >> - * >> * @exception InvalidKeyException if the given key is inappropriate for >> * initializing this cipher >> */ >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -225,7 +225,7 @@ >> * >> * @param key the key >> * >> - * @param keySpec the requested format in which the key material shall be >> + * @param keySpecCl the requested format in which the key material shall be >> * returned >> * >> * @return the underlying key specification (key material) in the >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 >> @@ -92,7 +92,7 @@ >> * Sets the padding mechanism of this cipher. This algorithm only uses >> * PKCS #5 padding. >> * >> - * @param padding the padding mechanism >> + * @param paddingScheme the padding mechanism >> * >> * @exception NoSuchPaddingException if the requested padding mechanism >> * is invalid >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2005, 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 >> @@ -75,7 +75,7 @@ >> * >> * @param key the key >> * >> - * @param keySpec the requested format in which the key material shall be >> + * @param keySpecCl the requested format in which the key material shall be >> * returned >> * >> * @return the underlying key specification (key material) in the >> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -49,7 +49,7 @@ >> * interface. >> * >> * @param in the input buffer with the data to pad >> - * @param the offset in `in` where the padding bytes >> + * @param off the offset in `in` where the padding bytes >> * are appended >> * @param len the number of padding bytes to add >> * >> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 >> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 >> @@ -1077,7 +1077,7 @@ >> * Start a new Process using an explicit array of redirects. >> * See {@link #start} for details of starting each Process. >> * >> - * @param redirect array of redirects for stdin, stdout, stderr >> + * @param redirects array of redirects for stdin, stdout, stderr >> * @return the new Process >> * @throws IOException if an I/O error occurs >> */ >> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 >> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 >> @@ -731,7 +731,7 @@ >> * Constructs an empty GregorianCalendar. >> * >> * @param zone the given time zone >> - * @param aLocale the given locale >> + * @param locale the given locale >> * @param flag the flag requesting an empty instance >> */ >> GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { >> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 >> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 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 >> @@ -316,7 +316,7 @@ >> * If the address already has a scope-id or if the address is not local, ipv6 >> * or link local, then the original address is returned. >> * >> - * @param addr >> + * @param address >> * @exception SocketException if the given ipv6 link local address is found >> * on more than one local interface >> * @return >> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 >> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 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 >> @@ -208,7 +208,7 @@ >> * Use New to get new HttpsClient. This constructor is meant to be >> * used only by New method. New properly checks for URL spoofing. >> * >> - * @param URL https URL with which a connection must be established >> + * @param url https URL with which a connection must be established >> */ >> private HttpsClient(SSLSocketFactory sf, URL url) >> throws IOException >> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 >> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 >> @@ -321,7 +321,7 @@ >> /** >> * Loads the provider with the specified class name. >> * >> - * @param name the name of the provider >> + * @param pn the name of the provider >> * @return the Provider, or null if it cannot be found or loaded >> * @throws ProviderException all other exceptions are ignored >> */ >> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 >> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2000, 2012, 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 >> @@ -72,7 +72,7 @@ >> * Constructor that initializes the input parameters. >> * >> * @param anchor the anchor selected to validate the target certificate >> - * @param testDate the time for which the validity of the certificate >> + * @param date the time for which the validity of the certificate >> * should be determined >> * @param sigProvider the name of the signature provider >> * @param sigOnly true if only signature checking is to be done; >> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 >> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2000, 2018, 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 >> @@ -69,7 +69,7 @@ >> /** >> * Initialize the builder with the input parameters. >> * >> - * @param params the parameter set used to build a certification path >> + * @param buildParams the parameter set used to build a certification path >> */ >> Builder(BuilderParams buildParams) { >> this.buildParams = buildParams; >> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 >> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 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 >> @@ -111,7 +111,7 @@ >> * @param ruleFile the name of the rule data file >> * @param ruleData the rule data loaded from the rule data file >> * @param dictionaryFile the name of the dictionary file >> - * @param dictionartData the dictionary data loaded from the dictionary file >> + * @param dictionaryData the dictionary data loaded from the dictionary file >> * @throws MissingResourceException if rule data or dictionary initialization failed >> */ >> public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, >> >> >>>> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >>>> >>>> Hi David, >>>> >>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >>>> Please suggest if there is any way I can create my user id to upload this patch. >>>> >>>> This is ~300 line patch file. >>>> >>>> Regards, >>>> Vipin >>>> >>>>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>>>> >>>>> Hi Vipin, >>>>> >>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>>>> Hi, >>>>>> I have fixed a few warnings where the method parameter name is different in >>>>>> code and Javadoc, need a sponsor for this patch. >>>>>> Webrev is available at >>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>>>> >>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards, >>>>>> Vipin >>>> >>> >> Thanks, >> Vipin > From daniel.fuchs at oracle.com Wed Apr 8 13:07:56 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Apr 2020 14:07:56 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: Hi Pavel, On 08/04/2020 13:56, David Holmes wrote: > and `@exception` tags for checked exceptions that were neither thrown > nor imported Hopefully that's only on internal classes. It might be prudent to separate this out in a different changeset. It's not always obvious where an exception is thrown. best regards, -- daniel From sean.mullan at oracle.com Wed Apr 8 13:10:28 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Apr 2020 09:10:28 -0400 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: The security changes look fine to me. --Sean On 4/8/20 7:50 AM, Pavel Rappo wrote: > Vipin, here you go: > > https://bugs.openjdk.java.net/browse/JDK-8242366 > http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ > > I took the liberty of additionally fixing a couple of parameters' names, > a typo, and `@exception` tags for checked exceptions that were neither thrown > nor imported. > > The bulk of the change is in Security. Some changes are in Networking. The > appropriate mailing lists are in CC for this email. We should wait for their > feedback. > > Changes in core area look good to me and I'd be surprised if there are any > problems with the remaining portion of the changeset. > > -Pavel > >> On 7 Apr 2020, at 19:50, Vipin Sharma wrote: >> >> Hi Pavel, >> >>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >>> >>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. >> Yes I have signed OCA. >>> >>> -Pavel >>> >>> [1] https://www.oracle.com/technetwork/community/oca-486395.html >>> [2] changeset: 58344:65f30e209890 >>> user: clanger >>> date: Wed Mar 11 13:50:13 2020 +0100 >>> files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java >>> description: >>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java >>> Reviewed-by: clanger, vtewari >>> Contributed-by: vipinsharma85 at gmail.com >>> >> Yes this is my first contribution. >> >> Patch text: >> >> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2002, 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 >> @@ -202,7 +202,7 @@ >> /** >> * Sets the padding mechanism of this cipher. >> * >> - * @param padding the padding mechanism >> + * @param paddingScheme the padding mechanism >> * >> * @exception NoSuchPaddingException if the requested padding mechanism >> * does not exist >> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 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 >> @@ -313,10 +313,10 @@ >> * current Cipher.engineInit(...) implementation, >> * IllegalStateException will always be thrown upon invocation. >> * >> - * @param in the input buffer >> - * @param inOffset the offset in `in` where the input >> + * @param input the input buffer >> + * @param inputOffset the offset in `in` where the input >> * starts >> - * @param inLen the input length. >> + * @param inputLen the input length. >> * >> * @return n/a. >> * >> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1998, 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 >> @@ -130,7 +130,6 @@ >> * >> * @param plain the buffer with the input data to be encrypted >> * @param plainOffset the offset in `plain` >> - * @param plainLen the length of the input data >> * @param cipher the buffer for the result >> * @param cipherOffset the offset in `cipher` >> */ >> @@ -154,7 +153,6 @@ >> * >> * @param cipher the buffer with the input data to be decrypted >> * @param cipherOffset the offset in `cipherOffset` >> - * @param cipherLen the length of the input data >> * @param plain the buffer for the result >> * @param plainOffset the offset in `plain` >> */ >> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -552,7 +552,6 @@ >> * >> * @param plain the buffer with the input data to be encrypted >> * @param plainOffset the offset in `plain` >> - * @param plainLen the length of the input data >> * @param cipher the buffer for the result >> * @param cipherOffset the offset in `cipher` >> * >> @@ -579,7 +578,6 @@ >> * >> * @param cipher the buffer with the input data to be decrypted >> * @param cipherOffset the offset in `cipherOffset` >> - * @param cipherLen the length of the input data >> * @param plain the buffer for the result >> * @param plainOffset the offset in `plain` >> * >> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2013, 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 >> @@ -262,8 +262,6 @@ >> * @param algorithm the algorithm name >> * @param key the key >> * @param iv the iv >> - * @param tagLenBytes the length of tag in bytes >> - * >> * @exception InvalidKeyException if the given key is inappropriate for >> * initializing this cipher >> */ >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -225,7 +225,7 @@ >> * >> * @param key the key >> * >> - * @param keySpec the requested format in which the key material shall be >> + * @param keySpecCl the requested format in which the key material shall be >> * returned >> * >> * @return the underlying key specification (key material) in the >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 >> @@ -92,7 +92,7 @@ >> * Sets the padding mechanism of this cipher. This algorithm only uses >> * PKCS #5 padding. >> * >> - * @param padding the padding mechanism >> + * @param paddingScheme the padding mechanism >> * >> * @exception NoSuchPaddingException if the requested padding mechanism >> * is invalid >> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2005, 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 >> @@ -75,7 +75,7 @@ >> * >> * @param key the key >> * >> - * @param keySpec the requested format in which the key material shall be >> + * @param keySpecCl the requested format in which the key material shall be >> * returned >> * >> * @return the underlying key specification (key material) in the >> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 >> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1997, 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 >> @@ -49,7 +49,7 @@ >> * interface. >> * >> * @param in the input buffer with the data to pad >> - * @param the offset in `in` where the padding bytes >> + * @param off the offset in `in` where the padding bytes >> * are appended >> * @param len the number of padding bytes to add >> * >> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 >> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 >> @@ -1077,7 +1077,7 @@ >> * Start a new Process using an explicit array of redirects. >> * See {@link #start} for details of starting each Process. >> * >> - * @param redirect array of redirects for stdin, stdout, stderr >> + * @param redirects array of redirects for stdin, stdout, stderr >> * @return the new Process >> * @throws IOException if an I/O error occurs >> */ >> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 >> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 >> @@ -731,7 +731,7 @@ >> * Constructs an empty GregorianCalendar. >> * >> * @param zone the given time zone >> - * @param aLocale the given locale >> + * @param locale the given locale >> * @param flag the flag requesting an empty instance >> */ >> GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { >> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 >> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 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 >> @@ -316,7 +316,7 @@ >> * If the address already has a scope-id or if the address is not local, ipv6 >> * or link local, then the original address is returned. >> * >> - * @param addr >> + * @param address >> * @exception SocketException if the given ipv6 link local address is found >> * on more than one local interface >> * @return >> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 >> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 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 >> @@ -208,7 +208,7 @@ >> * Use New to get new HttpsClient. This constructor is meant to be >> * used only by New method. New properly checks for URL spoofing. >> * >> - * @param URL https URL with which a connection must be established >> + * @param url https URL with which a connection must be established >> */ >> private HttpsClient(SSLSocketFactory sf, URL url) >> throws IOException >> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 >> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 >> @@ -321,7 +321,7 @@ >> /** >> * Loads the provider with the specified class name. >> * >> - * @param name the name of the provider >> + * @param pn the name of the provider >> * @return the Provider, or null if it cannot be found or loaded >> * @throws ProviderException all other exceptions are ignored >> */ >> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 >> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2000, 2012, 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 >> @@ -72,7 +72,7 @@ >> * Constructor that initializes the input parameters. >> * >> * @param anchor the anchor selected to validate the target certificate >> - * @param testDate the time for which the validity of the certificate >> + * @param date the time for which the validity of the certificate >> * should be determined >> * @param sigProvider the name of the signature provider >> * @param sigOnly true if only signature checking is to be done; >> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 >> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2000, 2018, 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 >> @@ -69,7 +69,7 @@ >> /** >> * Initialize the builder with the input parameters. >> * >> - * @param params the parameter set used to build a certification path >> + * @param buildParams the parameter set used to build a certification path >> */ >> Builder(BuilderParams buildParams) { >> this.buildParams = buildParams; >> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 >> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 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 >> @@ -111,7 +111,7 @@ >> * @param ruleFile the name of the rule data file >> * @param ruleData the rule data loaded from the rule data file >> * @param dictionaryFile the name of the dictionary file >> - * @param dictionartData the dictionary data loaded from the dictionary file >> + * @param dictionaryData the dictionary data loaded from the dictionary file >> * @throws MissingResourceException if rule data or dictionary initialization failed >> */ >> public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, >> >> >>>> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >>>> >>>> Hi David, >>>> >>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >>>> Please suggest if there is any way I can create my user id to upload this patch. >>>> >>>> This is ~300 line patch file. >>>> >>>> Regards, >>>> Vipin >>>> >>>>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>>>> >>>>> Hi Vipin, >>>>> >>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>>>> Hi, >>>>>> I have fixed a few warnings where the method parameter name is different in >>>>>> code and Javadoc, need a sponsor for this patch. >>>>>> Webrev is available at >>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>>>> >>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards, >>>>>> Vipin >>>> >>> >> Thanks, >> Vipin > From Alan.Bateman at oracle.com Wed Apr 8 13:14:51 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Apr 2020 14:14:51 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: On 08/04/2020 14:07, Daniel Fuchs wrote: > Hi Pavel, > > On 08/04/2020 13:56, David Holmes wrote: >> and `@exception` tags for checked exceptions that were neither thrown >> nor imported > > Hopefully that's only on internal classes. From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses. -Alan From pavel.rappo at oracle.com Wed Apr 8 13:23:40 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 8 Apr 2020 14:23:40 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com> Hey David, Where exactly? In the files affected by this changeset? If so, then we will introduce inconsistency. Otherwise it's a huge change. From what I can see there are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security} and some 7,300 in src. Personally, out of all tag renovations, changing `@exception` to `@throws` probably gives the least bang for the buck. If nothing else, it gives you 3 extra characters on the same line to fill with something more useful. I would be more inclined to change ``...`` to `{@code ...}`, but given how error-prone that can be, I still wouldn't do it in this changeset. -Pavel > On 8 Apr 2020, at 13:56, David Holmes wrote: > > Hi Pavel, > > Not a review ... > > On 8/04/2020 9:50 pm, Pavel Rappo wrote: >> Vipin, here you go: >> https://bugs.openjdk.java.net/browse/JDK-8242366 >> http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ >> I took the liberty of additionally fixing a couple of parameters' names, >> a typo, and `@exception` tags for checked exceptions that were neither thrown >> nor imported. > > While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.) > > Cheers, > David > >> The bulk of the change is in Security. Some changes are in Networking. The >> appropriate mailing lists are in CC for this email. We should wait for their >> feedback. >> Changes in core area look good to me and I'd be surprised if there are any >> problems with the remaining portion of the changeset. >> -Pavel >>> On 7 Apr 2020, at 19:50, Vipin Sharma wrote: >>> >>> Hi Pavel, >>> >>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >>>> >>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. >>> Yes I have signed OCA. >>>> >>>> -Pavel >>>> >>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html >>>> [2] changeset: 58344:65f30e209890 >>>> user: clanger >>>> date: Wed Mar 11 13:50:13 2020 +0100 >>>> files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java >>>> description: >>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java >>>> Reviewed-by: clanger, vtewari >>>> Contributed-by: vipinsharma85 at gmail.com >>>> >>> Yes this is my first contribution. >>> >>> Patch text: >>> >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2002, 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 >>> @@ -202,7 +202,7 @@ >>> /** >>> * Sets the padding mechanism of this cipher. >>> * >>> - * @param padding the padding mechanism >>> + * @param paddingScheme the padding mechanism >>> * >>> * @exception NoSuchPaddingException if the requested padding mechanism >>> * does not exist >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2004, 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 >>> @@ -313,10 +313,10 @@ >>> * current Cipher.engineInit(...) implementation, >>> * IllegalStateException will always be thrown upon invocation. >>> * >>> - * @param in the input buffer >>> - * @param inOffset the offset in `in` where the input >>> + * @param input the input buffer >>> + * @param inputOffset the offset in `in` where the input >>> * starts >>> - * @param inLen the input length. >>> + * @param inputLen the input length. >>> * >>> * @return n/a. >>> * >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1998, 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 >>> @@ -130,7 +130,6 @@ >>> * >>> * @param plain the buffer with the input data to be encrypted >>> * @param plainOffset the offset in `plain` >>> - * @param plainLen the length of the input data >>> * @param cipher the buffer for the result >>> * @param cipherOffset the offset in `cipher` >>> */ >>> @@ -154,7 +153,6 @@ >>> * >>> * @param cipher the buffer with the input data to be decrypted >>> * @param cipherOffset the offset in `cipherOffset` >>> - * @param cipherLen the length of the input data >>> * @param plain the buffer for the result >>> * @param plainOffset the offset in `plain` >>> */ >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1997, 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 >>> @@ -552,7 +552,6 @@ >>> * >>> * @param plain the buffer with the input data to be encrypted >>> * @param plainOffset the offset in `plain` >>> - * @param plainLen the length of the input data >>> * @param cipher the buffer for the result >>> * @param cipherOffset the offset in `cipher` >>> * >>> @@ -579,7 +578,6 @@ >>> * >>> * @param cipher the buffer with the input data to be decrypted >>> * @param cipherOffset the offset in `cipherOffset` >>> - * @param cipherLen the length of the input data >>> * @param plain the buffer for the result >>> * @param plainOffset the offset in `plain` >>> * >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2013, 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 >>> @@ -262,8 +262,6 @@ >>> * @param algorithm the algorithm name >>> * @param key the key >>> * @param iv the iv >>> - * @param tagLenBytes the length of tag in bytes >>> - * >>> * @exception InvalidKeyException if the given key is inappropriate for >>> * initializing this cipher >>> */ >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1997, 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 >>> @@ -225,7 +225,7 @@ >>> * >>> * @param key the key >>> * >>> - * @param keySpec the requested format in which the key material shall be >>> + * @param keySpecCl the requested format in which the key material shall be >>> * returned >>> * >>> * @return the underlying key specification (key material) in the >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 >>> @@ -92,7 +92,7 @@ >>> * Sets the padding mechanism of this cipher. This algorithm only uses >>> * PKCS #5 padding. >>> * >>> - * @param padding the padding mechanism >>> + * @param paddingScheme the padding mechanism >>> * >>> * @exception NoSuchPaddingException if the requested padding mechanism >>> * is invalid >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 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 >>> @@ -75,7 +75,7 @@ >>> * >>> * @param key the key >>> * >>> - * @param keySpec the requested format in which the key material shall be >>> + * @param keySpecCl the requested format in which the key material shall be >>> * returned >>> * >>> * @return the underlying key specification (key material) in the >>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 >>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1997, 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 >>> @@ -49,7 +49,7 @@ >>> * interface. >>> * >>> * @param in the input buffer with the data to pad >>> - * @param the offset in `in` where the padding bytes >>> + * @param off the offset in `in` where the padding bytes >>> * are appended >>> * @param len the number of padding bytes to add >>> * >>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 >>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 >>> @@ -1077,7 +1077,7 @@ >>> * Start a new Process using an explicit array of redirects. >>> * See {@link #start} for details of starting each Process. >>> * >>> - * @param redirect array of redirects for stdin, stdout, stderr >>> + * @param redirects array of redirects for stdin, stdout, stderr >>> * @return the new Process >>> * @throws IOException if an I/O error occurs >>> */ >>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 >>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 >>> @@ -731,7 +731,7 @@ >>> * Constructs an empty GregorianCalendar. >>> * >>> * @param zone the given time zone >>> - * @param aLocale the given locale >>> + * @param locale the given locale >>> * @param flag the flag requesting an empty instance >>> */ >>> GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { >>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 >>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2004, 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 >>> @@ -316,7 +316,7 @@ >>> * If the address already has a scope-id or if the address is not local, ipv6 >>> * or link local, then the original address is returned. >>> * >>> - * @param addr >>> + * @param address >>> * @exception SocketException if the given ipv6 link local address is found >>> * on more than one local interface >>> * @return >>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 >>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2001, 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 >>> @@ -208,7 +208,7 @@ >>> * Use New to get new HttpsClient. This constructor is meant to be >>> * used only by New method. New properly checks for URL spoofing. >>> * >>> - * @param URL https URL with which a connection must be established >>> + * @param url https URL with which a connection must be established >>> */ >>> private HttpsClient(SSLSocketFactory sf, URL url) >>> throws IOException >>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 >>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 >>> @@ -321,7 +321,7 @@ >>> /** >>> * Loads the provider with the specified class name. >>> * >>> - * @param name the name of the provider >>> + * @param pn the name of the provider >>> * @return the Provider, or null if it cannot be found or loaded >>> * @throws ProviderException all other exceptions are ignored >>> */ >>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 >>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2000, 2012, 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 >>> @@ -72,7 +72,7 @@ >>> * Constructor that initializes the input parameters. >>> * >>> * @param anchor the anchor selected to validate the target certificate >>> - * @param testDate the time for which the validity of the certificate >>> + * @param date the time for which the validity of the certificate >>> * should be determined >>> * @param sigProvider the name of the signature provider >>> * @param sigOnly true if only signature checking is to be done; >>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 >>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2000, 2018, 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 >>> @@ -69,7 +69,7 @@ >>> /** >>> * Initialize the builder with the input parameters. >>> * >>> - * @param params the parameter set used to build a certification path >>> + * @param buildParams the parameter set used to build a certification path >>> */ >>> Builder(BuilderParams buildParams) { >>> this.buildParams = buildParams; >>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 >>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 1999, 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 >>> @@ -111,7 +111,7 @@ >>> * @param ruleFile the name of the rule data file >>> * @param ruleData the rule data loaded from the rule data file >>> * @param dictionaryFile the name of the dictionary file >>> - * @param dictionartData the dictionary data loaded from the dictionary file >>> + * @param dictionaryData the dictionary data loaded from the dictionary file >>> * @throws MissingResourceException if rule data or dictionary initialization failed >>> */ >>> public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, >>> >>> >>>>> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >>>>> >>>>> Hi David, >>>>> >>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >>>>> Please suggest if there is any way I can create my user id to upload this patch. >>>>> >>>>> This is ~300 line patch file. >>>>> >>>>> Regards, >>>>> Vipin >>>>> >>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>>>>> >>>>>> Hi Vipin, >>>>>> >>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>>>>> Hi, >>>>>>> I have fixed a few warnings where the method parameter name is different in >>>>>>> code and Javadoc, need a sponsor for this patch. >>>>>>> Webrev is available at >>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>>>>> >>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Regards, >>>>>>> Vipin >>>>> >>>> >>> Thanks, >>> Vipin From pavel.rappo at oracle.com Wed Apr 8 13:27:28 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 8 Apr 2020 14:27:28 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com> Why assume something that sophisticated where it can be adequately explained by a simpler thing? :) I bet it was an IDE inspection. -Pavel > On 8 Apr 2020, at 14:14, Alan Bateman wrote: > > On 08/04/2020 14:07, Daniel Fuchs wrote: >> Hi Pavel, >> >> On 08/04/2020 13:56, David Holmes wrote: >>> and `@exception` tags for checked exceptions that were neither thrown >>> nor imported >> >> Hopefully that's only on internal classes. > From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses. > > -Alan From gil at azul.com Wed Apr 8 14:25:25 2020 From: gil at azul.com (Gil Tene) Date: Wed, 8 Apr 2020 14:25:25 +0000 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> A very welcome change overall. However, I have concerns about the semantic change to the PhantomReference specification. I propose that PhantomReference semantics remain unchanged, and that PhantomReference:RefersTo should return true only for null. See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 > On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: > > [Note review on both core-libs and hotspot-gc-dev lists; try not to lose > either when replying.] > > Please review a new function: java.lang.ref.Reference.refersTo. > > This function is needed to test the referent of a Reference object > without artificially extending the lifetime of the referent object, as > may happen when calling Reference.get. Some garbage collectors > require extending the lifetime of a weak referent when accessed, in > order to maintain collector invariants. Lifetime extension may occur > with any collector when the Reference is a SoftReference, as calling > get indicates recent access. This new function also allows testing > the referent of a PhantomReference, which can't be accessed by calling > get. > > The new function uses a native method whose implementation is in the > VM so it can use the Access API. It is the intent that this function > will be intrinsified by optimizing compilers like C2 or graal, but > that hasn't been implemented yet. Bear that in mind before rushing > off to change existing uses of Reference.get. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8188055 > https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ > > Testing: > mach5 tier1 > > Locally (linux-x64) verified the new test passes with various garbage > collectors. From daniel.fuchs at oracle.com Wed Apr 8 14:37:14 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Apr 2020 15:37:14 +0100 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> Message-ID: <3189b9da-c9e7-dae5-6869-b130783d7884@oracle.com> On 08/04/2020 12:50, Pavel Rappo wrote: > Vipin, here you go: > > https://bugs.openjdk.java.net/browse/JDK-8242366 > http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ Hi Pavel, That looks good to me. WRT to the @exception changes I'll leave that responsibility to Sean ;-) best regards, -- daniel > > I took the liberty of additionally fixing a couple of parameters' names, > a typo, and `@exception` tags for checked exceptions that were neither thrown > nor imported. From erik.osterlund at oracle.com Wed Apr 8 14:56:19 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 8 Apr 2020 16:56:19 +0200 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> References: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> Message-ID: Hi Gil, Lifting out my reply to you from the JIRA issue: In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something? Thanks, /Erik On 2020-04-08 16:25, Gil Tene wrote: > A very welcome change overall. However, I have concerns about > the semantic change to the PhantomReference specification. I propose > that PhantomReference semantics remain unchanged, and that > PhantomReference:RefersTo should return true only for null. > > See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 > >> On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: >> >> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >> either when replying.] >> >> Please review a new function: java.lang.ref.Reference.refersTo. >> >> This function is needed to test the referent of a Reference object >> without artificially extending the lifetime of the referent object, as >> may happen when calling Reference.get. Some garbage collectors >> require extending the lifetime of a weak referent when accessed, in >> order to maintain collector invariants. Lifetime extension may occur >> with any collector when the Reference is a SoftReference, as calling >> get indicates recent access. This new function also allows testing >> the referent of a PhantomReference, which can't be accessed by calling >> get. >> >> The new function uses a native method whose implementation is in the >> VM so it can use the Access API. It is the intent that this function >> will be intrinsified by optimizing compilers like C2 or graal, but >> that hasn't been implemented yet. Bear that in mind before rushing >> off to change existing uses of Reference.get. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8188055 >> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >> >> Testing: >> mach5 tier1 >> >> Locally (linux-x64) verified the new test passes with various garbage >> collectors. From Roger.Riggs at oracle.com Wed Apr 8 15:04:15 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 8 Apr 2020 11:04:15 -0400 Subject: RFR 15 8242382: test/jdk/TEST.groups cleanup of sun/tools/java Message-ID: Please review a trivial cleanup of test/jdk/TEST.groups to remove a latent reference to sun/tools/java. diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups --- a/test/jdk/TEST.groups +++ b/test/jdk/TEST.groups @@ -1,4 +1,4 @@ -#? Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. +#? Copyright (c) 2013, 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 @@ -264,13 +264,11 @@ jdk_launcher = \ ?core_tools = \ ???? tools \ ???? jdk/internal/jrtfs \ -??? sun/tools/java \ ???? sun/tools/jrunscript ?svc_tools = \ ???? com/sun/tools/attach \ ???? sun/tools \ -??? -sun/tools/java \ ???? -sun/tools/jrunscript \ ???? sun/jvmstat Issue: https://bugs.openjdk.java.net/browse/JDK-8242382 Thanks, Roger From lance.andersen at oracle.com Wed Apr 8 15:06:16 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 8 Apr 2020 11:06:16 -0400 Subject: RFR 15 8242382: test/jdk/TEST.groups cleanup of sun/tools/java In-Reply-To: References: Message-ID: +1 > On Apr 8, 2020, at 11:04 AM, Roger Riggs wrote: > > Please review a trivial cleanup of test/jdk/TEST.groups to remove > a latent reference to sun/tools/java. > > diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups > --- a/test/jdk/TEST.groups > +++ b/test/jdk/TEST.groups > @@ -1,4 +1,4 @@ > -# Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. > +# Copyright (c) 2013, 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 > @@ -264,13 +264,11 @@ jdk_launcher = \ > core_tools = \ > tools \ > jdk/internal/jrtfs \ > - sun/tools/java \ > sun/tools/jrunscript > > svc_tools = \ > com/sun/tools/attach \ > sun/tools \ > - -sun/tools/java \ > -sun/tools/jrunscript \ > sun/jvmstat > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8242382 > > Thanks, Roger > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Wed Apr 8 15:09:59 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Apr 2020 16:09:59 +0100 Subject: RFR 15 8242382: test/jdk/TEST.groups cleanup of sun/tools/java In-Reply-To: References: Message-ID: <9d150591-6127-f041-9d13-4b73d8e46985@oracle.com> Ship it! best regards, -- daniel On 08/04/2020 16:04, Roger Riggs wrote: > Please review a trivial cleanup of test/jdk/TEST.groups to remove > a latent reference to sun/tools/java. From evgeny.nikitin at oracle.com Wed Apr 8 15:11:03 2020 From: evgeny.nikitin at oracle.com (Evgeny Nikitin) Date: Wed, 8 Apr 2020 17:11:03 +0200 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: <50f83e79-9273-fbaf-be6e-f4e0060e4fc7@oracle.com> References: <70147008-45b8-0b7f-6691-50f8429c5369@oracle.com> <48fa1432-2931-bf03-5eb6-ef853950f98c@oracle.com> <50f83e79-9273-fbaf-be6e-f4e0060e4fc7@oracle.com> Message-ID: <428675e0-f09c-ac6b-f5ec-afc4190a6b45@oracle.com> Hi David, > > You can use printf rather than making a separate call to format. > Good point, I've missed that method. I'll fix it and ask Igor to change > the webrev. I finally decided to leave it as it is now, since printf doesn't add a newline and System.lineSeparator() is not shorter than String.format() :). Please let me know if you disagree. Best regards, Evgeny. On 2020-04-07 16:09, Evgeny Nikitin wrote: > Hi David, > > > why did you introduce a new block scope? > > To separate the action block from the other code. "A Poor/lazy man's > method". I've preferred to lay it out this way because it makes the code > more compact and easy to read (as opposing to looking for a only-once > used method in some other part of the file) and due to the confusing > name of OutputAnalyzer type (which I need as a storage for output, not > as some analyzer). Creating a method with OutputAnalyzer as a parameter > would make this method's purpose even more confusing. > > > You can use printf rather than making a separate call to format. > Good point, I've missed that method. I'll fix it and ask Igor to change > the webrev. > > Regards, > > Evgeny. > > On 2020-04-07 14:50, David Holmes wrote: >> Hi Evgeny, >> >> On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: >>> Hi David, >>> >>>> I'm not at all sure this is generally what we want for every single >>>> test that uses ProcessTools! But I'm willing it to see it trialed. >>> >>> Well, it's mostly used for test VM runs. In runs I performed >>> (artificial "failures" included) the amounts of output were very small. >>> >>>> Please run full tier testing at least to tier 6 and ideally beyond >>>> before pushing this. There are potential implications for temporary >>>> (and more permanent) disk usage as well as additional time needed to >>>> write files out to disk. (Hopefully these are generally small enough >>>> that this doesn't make a noticeable difference.) >>> Done, thanks for suggestion. The additional runs showed no problems. >> >> Good to know - thanks. >> >>> I've provided Igor with a slightly modified version (Added >>> notification about the output file into the main test's log). Please >>> review: >>> >>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ >> >> A couple of minor nits: >> >> ?397???????????? { >> >> why did you introduce a new block scope? >> >> ?404???????????????? System.out.println(String.format( >> >> You can use printf rather than making a separate call to format. >> >> No need to see any update if you chose to make it. >> >> Thanks, >> David >> ----- >> >>> Best Regards, >>> >>> Evgeny. >>> >>> On 2020-04-02 02:07, David Holmes wrote: >>>> Thanks for sharing this Igor! >>>> >>>> I'm not at all sure this is generally what we want for every single >>>> test that uses ProcessTools! But I'm willing it to see it trialed. >>>> >>>> Evgeny: Please run full tier testing at least to tier 6 and ideally >>>> beyond before pushing this. There are potential implications for >>>> temporary (and more permanent) disk usage as well as additional time >>>> needed to write files out to disk. (Hopefully these are generally >>>> small enough that this doesn't make a noticeable difference.) >>>> >>>> Thanks, >>>> David >>>> >>>> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>>>> Hi Evgeny, >>>>> >>>>> (widening the audience, given this affects not just hotspot >>>>> compiler, but hotspot tests as well as core libs tests in general) >>>>> >>>>> overall that looks good to me. one suggestion, for the ease of >>>>> failure analysis it might be worth to print out the names of >>>>> created files, although this might potentially clutter the output, >>>>> I don't think it'll be a problem given we already print out things >>>>> like 'Gathering output for process ...' , 'Waiting for >>>>> completion...' in LazyOutputBuffer. >>>>> >>>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>>> macosx-x64, sparcv9). >>>>> this doesn't include any of hotspot tiers, could you please also >>>>> run hs-tier1--4? >>>>> // you can use tierN jobs which include both jdk and hs parts. >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>>>> >>>>>> >>>>>> The bug had been created as a request to simplify investigation >>>>>> for compiler control tests failures. >>>>>> I found the functionality pretty generic and useful and made >>>>>> ProcessTools dump output as well as some diagnostic information >>>>>> for every executed process into a separate file. >>>>>> The diagnostic information contains cmdline, exit code, stdout and >>>>>> stderr. The output files are named like 'pid--output.log'. >>>>>> >>>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>>> macosx-x64, sparcv9). >>>>>> >>>>>> Please review, >>>>>> /Evgeny Nikitin. >>>>> From igor.ignatyev at oracle.com Wed Apr 8 15:19:40 2020 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Wed, 8 Apr 2020 08:19:40 -0700 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: <428675e0-f09c-ac6b-f5ec-afc4190a6b45@oracle.com> References: <428675e0-f09c-ac6b-f5ec-afc4190a6b45@oracle.com> Message-ID: <16A3371B-EABC-4955-902C-78EB079094DB@oracle.com> You can use %n in printf to get a system-specific newline. ? Igor > On Apr 8, 2020, at 8:12 AM, Evgeny Nikitin wrote: > > ?Hi David, > > > > You can use printf rather than making a separate call to format. > > Good point, I've missed that method. I'll fix it and ask Igor to change > > the webrev. > > I finally decided to leave it as it is now, since printf doesn't add a newline and System.lineSeparator() is not shorter than String.format() :). Please let me know if you disagree. > > Best regards, > Evgeny. > > >> On 2020-04-07 16:09, Evgeny Nikitin wrote: >> Hi David, >> > why did you introduce a new block scope? >> To separate the action block from the other code. "A Poor/lazy man's method". I've preferred to lay it out this way because it makes the code more compact and easy to read (as opposing to looking for a only-once used method in some other part of the file) and due to the confusing name of OutputAnalyzer type (which I need as a storage for output, not as some analyzer). Creating a method with OutputAnalyzer as a parameter would make this method's purpose even more confusing. >> > You can use printf rather than making a separate call to format. >> Good point, I've missed that method. I'll fix it and ask Igor to change the webrev. >> Regards, >> Evgeny. >>> On 2020-04-07 14:50, David Holmes wrote: >>> Hi Evgeny, >>> >>> On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: >>>> Hi David, >>>> >>>>> I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. >>>> >>>> Well, it's mostly used for test VM runs. In runs I performed (artificial "failures" included) the amounts of output were very small. >>>> >>>>> Please run full tier testing at least to tier 6 and ideally beyond before pushing this. There are potential implications for temporary (and more permanent) disk usage as well as additional time needed to write files out to disk. (Hopefully these are generally small enough that this doesn't make a noticeable difference.) >>>> Done, thanks for suggestion. The additional runs showed no problems. >>> >>> Good to know - thanks. >>> >>>> I've provided Igor with a slightly modified version (Added notification about the output file into the main test's log). Please review: >>>> >>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ >>> >>> A couple of minor nits: >>> >>> 397 { >>> >>> why did you introduce a new block scope? >>> >>> 404 System.out.println(String.format( >>> >>> You can use printf rather than making a separate call to format. >>> >>> No need to see any update if you chose to make it. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Best Regards, >>>> >>>> Evgeny. >>>> >>>> On 2020-04-02 02:07, David Holmes wrote: >>>>> Thanks for sharing this Igor! >>>>> >>>>> I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. >>>>> >>>>> Evgeny: Please run full tier testing at least to tier 6 and ideally beyond before pushing this. There are potential implications for temporary (and more permanent) disk usage as well as additional time needed to write files out to disk. (Hopefully these are generally small enough that this doesn't make a noticeable difference.) >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>>>>> Hi Evgeny, >>>>>> >>>>>> (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) >>>>>> >>>>>> overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out the names of created files, although this might potentially clutter the output, I don't think it'll be a problem given we already print out things like 'Gathering output for process ...' , 'Waiting for completion...' in LazyOutputBuffer. >>>>>> >>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >>>>>> this doesn't include any of hotspot tiers, could you please also run hs-tier1--4? >>>>>> // you can use tierN jobs which include both jdk and hs parts. >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>>>>> >>>>>>> >>>>>>> The bug had been created as a request to simplify investigation for compiler control tests failures. >>>>>>> I found the functionality pretty generic and useful and made ProcessTools dump output as well as some diagnostic information for every executed process into a separate file. >>>>>>> The diagnostic information contains cmdline, exit code, stdout and stderr. The output files are named like 'pid--output.log'. >>>>>>> >>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >>>>>>> >>>>>>> Please review, >>>>>>> /Evgeny Nikitin. >>>>>> From gil at azul.com Wed Apr 8 16:05:32 2020 From: gil at azul.com (Gil Tene) Date: Wed, 8 Apr 2020 16:05:32 +0000 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> Message-ID: Lifting out of response from the JIRA issue: I always worry when proposing a change to an existing invariant, and PhantomReference currently carries the stated and specified behavior of "the referent of a phantom reference is always inaccessible". I can imagine quite a few forms of gaining new information I do not otherwise have access to by using PhantomReference::RefersTo if it allowed me to examine the current referent of a phantom reference and test to see if it is (a) null or (b) a specific object I have a reference to. Both of those would provide me with information that is impossible for me to get according to current specifications. With that newly available information one can come up with all sorts of nice things to do... Think in terms of "side-channel" as an example of the sort of thinking black hats can apply to this new knowledge, but the potential attacks are not limited to side-channels. While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same information that (Reference.get() == obj) would, providing more information than that would be a change to the specified behavior of Reference types, which we should be extra paranoid about. Since PhantomReference::get returns null by definition, we should remain consistent with that in PhantomReference::refersTo > On Apr 8, 2020, at 7:56 AM, Erik ?sterlund wrote: > > Hi Gil, > > Lifting out my reply to you from the JIRA issue: > > In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something? > > Thanks, > /Erik > > On 2020-04-08 16:25, Gil Tene wrote: >> A very welcome change overall. However, I have concerns about >> the semantic change to the PhantomReference specification. I propose >> that PhantomReference semantics remain unchanged, and that >> PhantomReference:RefersTo should return true only for null. >> >> See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 >> >>> On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: >>> >>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >>> either when replying.] >>> >>> Please review a new function: java.lang.ref.Reference.refersTo. >>> >>> This function is needed to test the referent of a Reference object >>> without artificially extending the lifetime of the referent object, as >>> may happen when calling Reference.get. Some garbage collectors >>> require extending the lifetime of a weak referent when accessed, in >>> order to maintain collector invariants. Lifetime extension may occur >>> with any collector when the Reference is a SoftReference, as calling >>> get indicates recent access. This new function also allows testing >>> the referent of a PhantomReference, which can't be accessed by calling >>> get. >>> >>> The new function uses a native method whose implementation is in the >>> VM so it can use the Access API. It is the intent that this function >>> will be intrinsified by optimizing compilers like C2 or graal, but >>> that hasn't been implemented yet. Bear that in mind before rushing >>> off to change existing uses of Reference.get. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8188055 >>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >>> >>> Webrev: >>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >>> >>> Testing: >>> mach5 tier1 >>> >>> Locally (linux-x64) verified the new test passes with various garbage >>> collectors. From erik.osterlund at oracle.com Wed Apr 8 16:13:13 2020 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Wed, 8 Apr 2020 18:13:13 +0200 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: Message-ID: <3DF86052-4E64-45A7-A37A-B88E1D9CF64F@oracle.com> Hi Gil, Do you have an example exploit, or at least the gist of it? As I already said, any information exposed could have been just guessed (replace refersTo with random() and brute force). So if you can create an exploit based on the answer of refersTo, then your system is secure by chance. In other words, it is already compromised. Or have I missed something? Thanks, /Erik > On 8 Apr 2020, at 18:05, Gil Tene wrote: > > ?Lifting out of response from the JIRA issue: > > I always worry when proposing a change to an existing invariant, and > PhantomReference currently carries the stated and specified behavior > of "the referent of a phantom reference is always inaccessible". > > I can imagine quite a few forms of gaining new information I do not otherwise > have access to by using PhantomReference::RefersTo if it allowed me to examine > the current referent of a phantom reference and test to see if it is (a) null or (b) a > specific object I have a reference to. Both of those would provide me with information > that is impossible for me to get according to current specifications. With that newly > available information one can come up with all sorts of nice things to do... Think in > terms of "side-channel" as an example of the sort of thinking black hats can apply > to this new knowledge, but the potential attacks are not limited to side-channels. > > While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same > information that (Reference.get() == obj) would, providing more information than > that would be a change to the specified behavior of Reference types, which we > should be extra paranoid about. Since PhantomReference::get returns null by > definition, we should remain consistent with that in PhantomReference::refersTo > >> On Apr 8, 2020, at 7:56 AM, Erik ?sterlund wrote: >> >> Hi Gil, >> >> Lifting out my reply to you from the JIRA issue: >> >> In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something? >> >> Thanks, >> /Erik >> >>> On 2020-04-08 16:25, Gil Tene wrote: >>> A very welcome change overall. However, I have concerns about >>> the semantic change to the PhantomReference specification. I propose >>> that PhantomReference semantics remain unchanged, and that >>> PhantomReference:RefersTo should return true only for null. >>> >>> See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 >>> >>>> On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: >>>> >>>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >>>> either when replying.] >>>> >>>> Please review a new function: java.lang.ref.Reference.refersTo. >>>> >>>> This function is needed to test the referent of a Reference object >>>> without artificially extending the lifetime of the referent object, as >>>> may happen when calling Reference.get. Some garbage collectors >>>> require extending the lifetime of a weak referent when accessed, in >>>> order to maintain collector invariants. Lifetime extension may occur >>>> with any collector when the Reference is a SoftReference, as calling >>>> get indicates recent access. This new function also allows testing >>>> the referent of a PhantomReference, which can't be accessed by calling >>>> get. >>>> >>>> The new function uses a native method whose implementation is in the >>>> VM so it can use the Access API. It is the intent that this function >>>> will be intrinsified by optimizing compilers like C2 or graal, but >>>> that hasn't been implemented yet. Bear that in mind before rushing >>>> off to change existing uses of Reference.get. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8188055 >>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >>>> >>>> Webrev: >>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >>>> >>>> Testing: >>>> mach5 tier1 >>>> >>>> Locally (linux-x64) verified the new test passes with various garbage >>>> collectors. > From mandy.chung at oracle.com Wed Apr 8 16:19:37 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Apr 2020 09:19:37 -0700 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: References: <866762F3-AAB4-4673-80D1-841CE71513DC@azul.com> Message-ID: <3b5fd0cf-5bfe-ebef-33fb-d25b88341ff0@oracle.com> I agree with Gil on this point. ? `PhantomReference::get` always returns null.?? The intent behavior of `ref.refersTo(obj)` is the same as `ref.get() == obj`.??? Gil's proposed option to have `refersTo(obj)` to return true only if obj is null is a reasonable one. If `PhantomReference::get` were to change to have the same behavior as other references some day, then `PhantomReference::refersTo` would be updated at that time (but no proposal doing that at the moment). Mandy On 4/8/20 9:05 AM, Gil Tene wrote: > Lifting out of response from the JIRA issue: > > I always worry when proposing a change to an existing invariant, and > PhantomReference currently carries the stated and specified behavior > of "the referent of a phantom reference is always inaccessible". > > I can imagine quite a few forms of gaining new information I do not otherwise > have access to by using PhantomReference::RefersTo if it allowed me to examine > the current referent of a phantom reference and test to see if it is (a) null or (b) a > specific object I have a reference to. Both of those would provide me with information > that is impossible for me to get according to current specifications. With that newly > available information one can come up with all sorts of nice things to do... Think in > terms of "side-channel" as an example of the sort of thinking black hats can apply > to this new knowledge, but the potential attacks are not limited to side-channels. > > While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same > information that (Reference.get() == obj) would, providing more information than > that would be a change to the specified behavior of Reference types, which we > should be extra paranoid about. Since PhantomReference::get returns null by > definition, we should remain consistent with that in PhantomReference::refersTo > >> On Apr 8, 2020, at 7:56 AM, Erik ?sterlund wrote: >> >> Hi Gil, >> >> Lifting out my reply to you from the JIRA issue: >> >> In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something? >> >> Thanks, >> /Erik >> >> On 2020-04-08 16:25, Gil Tene wrote: >>> A very welcome change overall. However, I have concerns about >>> the semantic change to the PhantomReference specification. I propose >>> that PhantomReference semantics remain unchanged, and that >>> PhantomReference:RefersTo should return true only for null. >>> >>> See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 >>> >>>> On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: >>>> >>>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >>>> either when replying.] >>>> >>>> Please review a new function: java.lang.ref.Reference.refersTo. >>>> >>>> This function is needed to test the referent of a Reference object >>>> without artificially extending the lifetime of the referent object, as >>>> may happen when calling Reference.get. Some garbage collectors >>>> require extending the lifetime of a weak referent when accessed, in >>>> order to maintain collector invariants. Lifetime extension may occur >>>> with any collector when the Reference is a SoftReference, as calling >>>> get indicates recent access. This new function also allows testing >>>> the referent of a PhantomReference, which can't be accessed by calling >>>> get. >>>> >>>> The new function uses a native method whose implementation is in the >>>> VM so it can use the Access API. It is the intent that this function >>>> will be intrinsified by optimizing compilers like C2 or graal, but >>>> that hasn't been implemented yet. Bear that in mind before rushing >>>> off to change existing uses of Reference.get. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8188055 >>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >>>> >>>> Webrev: >>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >>>> >>>> Testing: >>>> mach5 tier1 >>>> >>>> Locally (linux-x64) verified the new test passes with various garbage >>>> collectors. From vipinsharma85 at gmail.com Wed Apr 8 16:35:34 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Wed, 8 Apr 2020 22:05:34 +0530 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com> References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com> Message-ID: <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com> > On Apr 8, 2020, at 6:57 PM, Pavel Rappo wrote: > > Why assume something that sophisticated where it can be adequately explained by > a simpler thing? :) I bet it was an IDE inspection. > > -Pavel Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process. If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think? > >> On 8 Apr 2020, at 14:14, Alan Bateman wrote: >> >> On 08/04/2020 14:07, Daniel Fuchs wrote: >>> Hi Pavel, >>> >>> On 08/04/2020 13:56, David Holmes wrote: >>>> and `@exception` tags for checked exceptions that were neither thrown >>>> nor imported >>> >>> Hopefully that's only on internal classes. >> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses. >> >> -Alan > Regards, Vipin From evgeny.nikitin at oracle.com Wed Apr 8 17:27:16 2020 From: evgeny.nikitin at oracle.com (Evgeny Nikitin) Date: Wed, 8 Apr 2020 19:27:16 +0200 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: <16A3371B-EABC-4955-902C-78EB079094DB@oracle.com> References: <428675e0-f09c-ac6b-f5ec-afc4190a6b45@oracle.com> <16A3371B-EABC-4955-902C-78EB079094DB@oracle.com> Message-ID: Thanks to Igor Ignatyev, a new version is available at http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.02 Regards, Evgeny. On 2020-04-08 17:19, Igor Ignatev wrote: > You can use %n in printf to get a system-specific newline. > > ? Igor > >> On Apr 8, 2020, at 8:12 AM, Evgeny Nikitin wrote: >> >> ?Hi David, >> >>> > You can use printf rather than making a separate call to format. >>> Good point, I've missed that method. I'll fix it and ask Igor to change >>> the webrev. >> >> I finally decided to leave it as it is now, since printf doesn't add a newline and System.lineSeparator() is not shorter than String.format() :). Please let me know if you disagree. >> >> Best regards, >> Evgeny. >> >> >>> On 2020-04-07 16:09, Evgeny Nikitin wrote: >>> Hi David, >>>> why did you introduce a new block scope? >>> To separate the action block from the other code. "A Poor/lazy man's method". I've preferred to lay it out this way because it makes the code more compact and easy to read (as opposing to looking for a only-once used method in some other part of the file) and due to the confusing name of OutputAnalyzer type (which I need as a storage for output, not as some analyzer). Creating a method with OutputAnalyzer as a parameter would make this method's purpose even more confusing. >>>> You can use printf rather than making a separate call to format. >>> Good point, I've missed that method. I'll fix it and ask Igor to change the webrev. >>> Regards, >>> Evgeny. >>>> On 2020-04-07 14:50, David Holmes wrote: >>>> Hi Evgeny, >>>> >>>> On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: >>>>> Hi David, >>>>> >>>>>> I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. >>>>> >>>>> Well, it's mostly used for test VM runs. In runs I performed (artificial "failures" included) the amounts of output were very small. >>>>> >>>>>> Please run full tier testing at least to tier 6 and ideally beyond before pushing this. There are potential implications for temporary (and more permanent) disk usage as well as additional time needed to write files out to disk. (Hopefully these are generally small enough that this doesn't make a noticeable difference.) >>>>> Done, thanks for suggestion. The additional runs showed no problems. >>>> >>>> Good to know - thanks. >>>> >>>>> I've provided Igor with a slightly modified version (Added notification about the output file into the main test's log). Please review: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ >>>> >>>> A couple of minor nits: >>>> >>>> 397 { >>>> >>>> why did you introduce a new block scope? >>>> >>>> 404 System.out.println(String.format( >>>> >>>> You can use printf rather than making a separate call to format. >>>> >>>> No need to see any update if you chose to make it. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best Regards, >>>>> >>>>> Evgeny. >>>>> >>>>> On 2020-04-02 02:07, David Holmes wrote: >>>>>> Thanks for sharing this Igor! >>>>>> >>>>>> I'm not at all sure this is generally what we want for every single test that uses ProcessTools! But I'm willing it to see it trialed. >>>>>> >>>>>> Evgeny: Please run full tier testing at least to tier 6 and ideally beyond before pushing this. There are potential implications for temporary (and more permanent) disk usage as well as additional time needed to write files out to disk. (Hopefully these are generally small enough that this doesn't make a noticeable difference.) >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>>>>>> Hi Evgeny, >>>>>>> >>>>>>> (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) >>>>>>> >>>>>>> overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out the names of created files, although this might potentially clutter the output, I don't think it'll be a problem given we already print out things like 'Gathering output for process ...' , 'Waiting for completion...' in LazyOutputBuffer. >>>>>>> >>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >>>>>>> this doesn't include any of hotspot tiers, could you please also run hs-tier1--4? >>>>>>> // you can use tierN jobs which include both jdk and hs parts. >>>>>>> >>>>>>> Thanks, >>>>>>> -- Igor >>>>>>> >>>>>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> The bug had been created as a request to simplify investigation for compiler control tests failures. >>>>>>>> I found the functionality pretty generic and useful and made ProcessTools dump output as well as some diagnostic information for every executed process into a separate file. >>>>>>>> The diagnostic information contains cmdline, exit code, stdout and stderr. The output files are named like 'pid--output.log'. >>>>>>>> >>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 through 4) on the 4 common platforms (linux-x64, windows-x64, macosx-x64, sparcv9). >>>>>>>> >>>>>>>> Please review, >>>>>>>> /Evgeny Nikitin. >>>>>>> > From naoto.sato at oracle.com Wed Apr 8 17:29:16 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 8 Apr 2020 10:29:16 -0700 Subject: [15] RFR (XXS): 8242337: javadoc typo in NumberFormat::setMinimumFractionDigits Message-ID: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8242337 Here is the proposed diff: --- diff -r 706df347bcc2 src/java.base/share/classes/java/text/NumberFormat.java --- a/src/java.base/share/classes/java/text/NumberFormat.java +++ b/src/java.base/share/classes/java/text/NumberFormat.java @@ -865,7 +865,7 @@ * Sets the minimum number of digits allowed in the fraction portion of a * number. minimumFractionDigits must be ≤ maximumFractionDigits. If the * new value for minimumFractionDigits exceeds the current value - * of maximumFractionDigits, then maximumIntegerDigits will also be set to + * of maximumFractionDigits, then maximumFractionDigits will also be set to * the new value * * @param newValue the minimum number of fraction digits to be shown; if --- It is simply fixing a typo (possibly a copy/paste mistake). Thanks to Martin for finding this. Naoto From lance.andersen at oracle.com Wed Apr 8 17:30:50 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 8 Apr 2020 13:30:50 -0400 Subject: [15] RFR (XXS): 8242337: javadoc typo in NumberFormat::setMinimumFractionDigits In-Reply-To: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com> References: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com> Message-ID: <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com> +1 > On Apr 8, 2020, at 1:29 PM, naoto.sato at oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8242337 > > Here is the proposed diff: > > --- > diff -r 706df347bcc2 src/java.base/share/classes/java/text/NumberFormat.java > --- a/src/java.base/share/classes/java/text/NumberFormat.java > +++ b/src/java.base/share/classes/java/text/NumberFormat.java > @@ -865,7 +865,7 @@ > * Sets the minimum number of digits allowed in the fraction portion of a > * number. minimumFractionDigits must be ≤ maximumFractionDigits. If the > * new value for minimumFractionDigits exceeds the current value > - * of maximumFractionDigits, then maximumIntegerDigits will also be set to > + * of maximumFractionDigits, then maximumFractionDigits will also be set to > * the new value > * > * @param newValue the minimum number of fraction digits to be shown; if > --- > > It is simply fixing a typo (possibly a copy/paste mistake). Thanks to Martin for finding this. > > 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 martinrb at google.com Wed Apr 8 18:22:45 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Apr 2020 11:22:45 -0700 Subject: [15] RFR (XXS): 8242337: javadoc typo in NumberFormat::setMinimumFractionDigits In-Reply-To: <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com> References: <1a8bcacf-8800-2800-2b4d-38e8164081dc@oracle.com> <93DF6023-CD19-4D32-94F9-23EB872C118B@oracle.com> Message-ID: +1 ! From gil at azul.com Wed Apr 8 19:41:18 2020 From: gil at azul.com (Gil Tene) Date: Wed, 8 Apr 2020 19:41:18 +0000 Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate In-Reply-To: <3DF86052-4E64-45A7-A37A-B88E1D9CF64F@oracle.com> References: <3DF86052-4E64-45A7-A37A-B88E1D9CF64F@oracle.com> Message-ID: <2E3DBE75-3693-4BA8-B913-A5EBB5BD1451@azul.com> Erik, The fact that you have access to the objects involved (and to their contents) does not mean you already have access to the new information revealed by being able to check if a phantom reference refers to some specific object. Knowing "who uses what thing" is a lot more than just knowing "who exists" and "what are the things that exist"? Many security things leverage the fundamental difference between those sets of knowledge, and that's why we e.g. fear the effect that the emergence of quantum will likely have on on existing TLS ciphers... I could probably come up with a "reasonable code" example that would make security or correctness assumptions based on the currently specified opaqueness of phantom references, and which one would then be able to write an exploit against if we change the specified behavior . E.g. it would currently be reasonable to make use of phantom references across APIs as forms of a weak and opaque identity handles (and opposed to WeakReference which would be a weak but non-opaque handle), and build security or correctness assumptions based on that presumed opaqueness. We could go through an exercise of actually building one of these to prove a point. But we don't need an actual example exploit or a proof that the change can lead to security or correctness issues. We just need enough of a worry that such issues can arise due to the change. What I'm pointing to is the worry, and suggesting that the change in semantics is not necessary. I could phrase the issue in reverse: "What are examples where being able to determine if a phantom reference refers to a specific object is useful?" I have a feeling that at least some of those examples would also provide us with the exploit examples you ask for ;-) ? Gil. > On Apr 8, 2020, at 9:13 AM, Erik ?sterlund wrote: > > Hi Gil, > > Do you have an example exploit, or at least the gist of it? As I already said, any information exposed could have been just guessed (replace refersTo with random() and brute force). So if you can create an exploit based on the answer of refersTo, then your system is secure by chance. In other words, it is already compromised. Or have I missed something? > > Thanks, > /Erik > >> On 8 Apr 2020, at 18:05, Gil Tene wrote: >> >> ?Lifting out of response from the JIRA issue: >> >> I always worry when proposing a change to an existing invariant, and >> PhantomReference currently carries the stated and specified behavior >> of "the referent of a phantom reference is always inaccessible". >> >> I can imagine quite a few forms of gaining new information I do not otherwise >> have access to by using PhantomReference::RefersTo if it allowed me to examine >> the current referent of a phantom reference and test to see if it is (a) null or (b) a >> specific object I have a reference to. Both of those would provide me with information >> that is impossible for me to get according to current specifications. With that newly >> available information one can come up with all sorts of nice things to do... Think in >> terms of "side-channel" as an example of the sort of thinking black hats can apply >> to this new knowledge, but the potential attacks are not limited to side-channels. >> >> While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same >> information that (Reference.get() == obj) would, providing more information than >> that would be a change to the specified behavior of Reference types, which we >> should be extra paranoid about. Since PhantomReference::get returns null by >> definition, we should remain consistent with that in PhantomReference::refersTo >> >>> On Apr 8, 2020, at 7:56 AM, Erik ?sterlund wrote: >>> >>> Hi Gil, >>> >>> Lifting out my reply to you from the JIRA issue: >>> >>> In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something? >>> >>> Thanks, >>> /Erik >>> >>>> On 2020-04-08 16:25, Gil Tene wrote: >>>> A very welcome change overall. However, I have concerns about >>>> the semantic change to the PhantomReference specification. I propose >>>> that PhantomReference semantics remain unchanged, and that >>>> PhantomReference:RefersTo should return true only for null. >>>> >>>> See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 >>>> >>>>> On Apr 7, 2020, at 5:25 PM, Kim Barrett wrote: >>>>> >>>>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >>>>> either when replying.] >>>>> >>>>> Please review a new function: java.lang.ref.Reference.refersTo. >>>>> >>>>> This function is needed to test the referent of a Reference object >>>>> without artificially extending the lifetime of the referent object, as >>>>> may happen when calling Reference.get. Some garbage collectors >>>>> require extending the lifetime of a weak referent when accessed, in >>>>> order to maintain collector invariants. Lifetime extension may occur >>>>> with any collector when the Reference is a SoftReference, as calling >>>>> get indicates recent access. This new function also allows testing >>>>> the referent of a PhantomReference, which can't be accessed by calling >>>>> get. >>>>> >>>>> The new function uses a native method whose implementation is in the >>>>> VM so it can use the Access API. It is the intent that this function >>>>> will be intrinsified by optimizing compilers like C2 or graal, but >>>>> that hasn't been implemented yet. Bear that in mind before rushing >>>>> off to change existing uses of Reference.get. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8188055 >>>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >>>>> >>>>> Webrev: >>>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >>>>> >>>>> Testing: >>>>> mach5 tier1 >>>>> >>>>> Locally (linux-x64) verified the new test passes with various garbage >>>>> collectors. >> From stuart.marks at oracle.com Wed Apr 8 21:01:31 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 8 Apr 2020 14:01:31 -0700 Subject: RFR 15 8242327: List spec should state that unmodifiable lists implement RandomAccess Message-ID: Hi all, Please review this small change to the List interface that specifies that unmodifiable lists (returned by List.of et al) implement the RandomAccess marker interface. In fact, they already do; the intent of this section was to specify the user-visible characteristics of such lists, but this particular characteristic was accidentally omitted. https://bugs.openjdk.java.net/browse/JDK-8242327 Patch below. I'll follow up with a CSR request. Thanks, s'marks # HG changeset patch # User smarks # Date 1586379408 25200 # Wed Apr 08 13:56:48 2020 -0700 # Node ID f0b78a923c2b2eadfc79cfec7f65377588f10574 # Parent 46108b5b69d92dd424b73b828454849c397509cb 8242327: List spec should state that unmodifiable lists implement RandomAccess Reviewed-by: XXX diff -r 46108b5b69d9 -r f0b78a923c2b src/java.base/share/classes/java/util/List.java --- a/src/java.base/share/classes/java/util/List.java Tue Apr 07 16:31:46 2020 -0700 +++ b/src/java.base/share/classes/java/util/List.java Wed Apr 08 13:56:48 2020 -0700 @@ -104,6 +104,7 @@ *

• They are serializable if all elements are serializable. *
• The order of elements in the list is the same as the order of the * provided arguments, or of the elements in the provided array. + *
• The lists and their {@link subList subList} views implement the {@link RandomAccess} interface. *
• They are serializable if all elements are serializable. > *
• The order of elements in the list is the same as the order of the > * provided arguments, or of the elements in the provided array. > + *
• The lists and their {@link subList subList} views implement the {@link RandomAccess} interface. > *
• They are value-based. > * Callers should make no assumptions about the identity of the returned instances. > * Factories are free to create new instances or reuse existing ones. Therefore, > 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 Apr 8 23:23:34 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Wed, 8 Apr 2020 16:23:34 -0700 Subject: RFR: JDK-8242155: Enhance automated macos signing tests In-Reply-To: <3d7f8b6c-ccc9-251a-453e-e168ec4295b0@oracle.com> References: <3d7f8b6c-ccc9-251a-453e-e168ec4295b0@oracle.com> Message-ID: Hi Andy, Looks good. Thanks, Alexander On 4/8/20 2:14 PM, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8242155 > > [2] http://cr.openjdk.java.net/~herrick/8242155/webrev.01/ > > /Andy > From huizhe.wang at oracle.com Wed Apr 8 23:28:31 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 8 Apr 2020 16:28:31 -0700 Subject: RFR [15/java.xml] 8237187 Obsolete references to java.sun.com Message-ID: Please review a doc-only change to replace links to sun.com with ones to oracle.com. Only material changes were the two sun.com links, others format, e.g. moving the anchor brackets to within one line. --- a/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java +++ b/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java @@ -40,14 +40,14 @@ ?/** ? * XML non-validating push parser. - * - * This non-validating parser conforms to Extensible Markup Language (XML) 1.0 and "Namespaces in XML" - * specifications. The API supported by the parser are CLDC - * 1.0 and JSR-280, a - * JavaME subset of JAXP + *

+ * This non-validating parser conforms to + * Extensible Markup Language (XML) 1.0 and + * Namespaces in XML + * specifications. The API supported by the parser are + * CLDC and + * JSR-280, a JavaME subset of + * JAXP ? * and SAX2. ? * ? * @see org.xml.sax.XMLReader Thanks, Joe From lance.andersen at oracle.com Wed Apr 8 23:34:20 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 8 Apr 2020 19:34:20 -0400 Subject: RFR [15/java.xml] 8237187 Obsolete references to java.sun.com In-Reply-To: References: Message-ID: <1BF26614-C5B8-46EE-9345-26D6875C0F59@oracle.com> +1 > On Apr 8, 2020, at 7:28 PM, Joe Wang wrote: > > Please review a doc-only change to replace links to sun.com with ones to oracle.com. Only material changes were the two sun.com links, others format, e.g. moving the anchor brackets to within one line. > > --- a/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java > +++ b/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java > @@ -40,14 +40,14 @@ > > /** > * XML non-validating push parser. > - * > - * This non-validating parser conforms to - * >Extensible Markup Language (XML) 1.0 and - * href="http://www.w3.org/TR/REC-xml-names" >"Namespaces in XML" > - * specifications. The API supported by the parser are - * href="http://java.sun.com/aboutJava/communityprocess/final/jsr030/index.html">CLDC > - * 1.0 and JSR-280, a > - * JavaME subset of JAXP > + *

> + * This non-validating parser conforms to > + * Extensible Markup Language (XML) 1.0 and > + * Namespaces in XML > + * specifications. The API supported by the parser are > + * CLDC and > + * JSR-280, a JavaME subset of > + * JAXP > * and SAX2. > * > * @see org.xml.sax.XMLReader > > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Thu Apr 9 00:16:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Apr 2020 10:16:45 +1000 Subject: Need sponsor to fix Javadoc warnings In-Reply-To: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com> References: <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com> <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com> <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com> <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com> Message-ID: <6111470b-2fc5-2dc0-2b67-3e93ccc03f41@oracle.com> Hi Pavel, On 8/04/2020 11:23 pm, Pavel Rappo wrote: > Hey David, > > Where exactly? In the files affected by this changeset? If so, then we will > introduce inconsistency. Otherwise it's a huge change. From what I can see there > are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security} > and some 7,300 in src. Okay as I said I didn't examine in detail to see the size of the change - and its obviously too big. > Personally, out of all tag renovations, changing `@exception` to `@throws` > probably gives the least bang for the buck. If nothing else, it gives you 3 > extra characters on the same line to fill with something more useful. There was an effort to do this conversion a while back, at least while touching affected files. It's not a big deal to me. Cheers, David > I would be more inclined to change ``...`` to `{@code ...}`, but > given how error-prone that can be, I still wouldn't do it in this changeset. > > -Pavel > >> On 8 Apr 2020, at 13:56, David Holmes wrote: >> >> Hi Pavel, >> >> Not a review ... >> >> On 8/04/2020 9:50 pm, Pavel Rappo wrote: >>> Vipin, here you go: >>> https://bugs.openjdk.java.net/browse/JDK-8242366 >>> http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ >>> I took the liberty of additionally fixing a couple of parameters' names, >>> a typo, and `@exception` tags for checked exceptions that were neither thrown >>> nor imported. >> >> While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.) >> >> Cheers, >> David >> >>> The bulk of the change is in Security. Some changes are in Networking. The >>> appropriate mailing lists are in CC for this email. We should wait for their >>> feedback. >>> Changes in core area look good to me and I'd be surprised if there are any >>> problems with the remaining portion of the changeset. >>> -Pavel >>>> On 7 Apr 2020, at 19:50, Vipin Sharma wrote: >>>> >>>> Hi Pavel, >>>> >>>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >>>>> >>>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. >>>> Yes I have signed OCA. >>>>> >>>>> -Pavel >>>>> >>>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html >>>>> [2] changeset: 58344:65f30e209890 >>>>> user: clanger >>>>> date: Wed Mar 11 13:50:13 2020 +0100 >>>>> files: test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java >>>>> description: >>>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java >>>>> Reviewed-by: clanger, vtewari >>>>> Contributed-by: vipinsharma85 at gmail.com >>>>> >>>> Yes this is my first contribution. >>>> >>>> Patch text: >>>> >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.546117441 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java 2020-04-06 00:19:10.130115855 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2002, 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 >>>> @@ -202,7 +202,7 @@ >>>> /** >>>> * Sets the padding mechanism of this cipher. >>>> * >>>> - * @param padding the padding mechanism >>>> + * @param paddingScheme the padding mechanism >>>> * >>>> * @exception NoSuchPaddingException if the requested padding mechanism >>>> * does not exist >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.526121179 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java 2020-04-06 00:19:11.118119622 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2004, 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 >>>> @@ -313,10 +313,10 @@ >>>> * current Cipher.engineInit(...) implementation, >>>> * IllegalStateException will always be thrown upon invocation. >>>> * >>>> - * @param in the input buffer >>>> - * @param inOffset the offset in `in` where the input >>>> + * @param input the input buffer >>>> + * @param inputOffset the offset in `in` where the input >>>> * starts >>>> - * @param inLen the input length. >>>> + * @param inputLen the input length. >>>> * >>>> * @return n/a. >>>> * >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.462124749 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java 2020-04-06 00:19:12.054123193 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1998, 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 >>>> @@ -130,7 +130,6 @@ >>>> * >>>> * @param plain the buffer with the input data to be encrypted >>>> * @param plainOffset the offset in `plain` >>>> - * @param plainLen the length of the input data >>>> * @param cipher the buffer for the result >>>> * @param cipherOffset the offset in `cipher` >>>> */ >>>> @@ -154,7 +153,6 @@ >>>> * >>>> * @param cipher the buffer with the input data to be decrypted >>>> * @param cipherOffset the offset in `cipherOffset` >>>> - * @param cipherLen the length of the input data >>>> * @param plain the buffer for the result >>>> * @param plainOffset the offset in `plain` >>>> */ >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:13.414128382 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java 2020-04-06 00:19:12.998126795 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1997, 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 >>>> @@ -552,7 +552,6 @@ >>>> * >>>> * @param plain the buffer with the input data to be encrypted >>>> * @param plainOffset the offset in `plain` >>>> - * @param plainLen the length of the input data >>>> * @param cipher the buffer for the result >>>> * @param cipherOffset the offset in `cipher` >>>> * >>>> @@ -579,7 +578,6 @@ >>>> * >>>> * @param cipher the buffer with the input data to be decrypted >>>> * @param cipherOffset the offset in `cipherOffset` >>>> - * @param cipherLen the length of the input data >>>> * @param plain the buffer for the result >>>> * @param plainOffset the offset in `plain` >>>> * >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:14.374132046 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java 2020-04-06 00:19:13.958130458 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2013, 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 >>>> @@ -262,8 +262,6 @@ >>>> * @param algorithm the algorithm name >>>> * @param key the key >>>> * @param iv the iv >>>> - * @param tagLenBytes the length of tag in bytes >>>> - * >>>> * @exception InvalidKeyException if the given key is inappropriate for >>>> * initializing this cipher >>>> */ >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:15.314135635 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java 2020-04-06 00:19:14.898134047 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1997, 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 >>>> @@ -225,7 +225,7 @@ >>>> * >>>> * @param key the key >>>> * >>>> - * @param keySpec the requested format in which the key material shall be >>>> + * @param keySpecCl the requested format in which the key material shall be >>>> * returned >>>> * >>>> * @return the underlying key specification (key material) in the >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:16.270139285 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java 2020-04-06 00:19:15.846137666 +0530 >>>> @@ -92,7 +92,7 @@ >>>> * Sets the padding mechanism of this cipher. This algorithm only uses >>>> * PKCS #5 padding. >>>> * >>>> - * @param padding the padding mechanism >>>> + * @param paddingScheme the padding mechanism >>>> * >>>> * @exception NoSuchPaddingException if the requested padding mechanism >>>> * is invalid >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:17.206142859 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java 2020-04-06 00:19:16.798141302 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2005, 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 >>>> @@ -75,7 +75,7 @@ >>>> * >>>> * @param key the key >>>> * >>>> - * @param keySpec the requested format in which the key material shall be >>>> + * @param keySpecCl the requested format in which the key material shall be >>>> * returned >>>> * >>>> * @return the underlying key specification (key material) in the >>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:18.138146421 +0530 >>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java 2020-04-06 00:19:17.722144831 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1997, 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 >>>> @@ -49,7 +49,7 @@ >>>> * interface. >>>> * >>>> * @param in the input buffer with the data to pad >>>> - * @param the offset in `in` where the padding bytes >>>> + * @param off the offset in `in` where the padding bytes >>>> * are appended >>>> * @param len the number of padding bytes to add >>>> * >>>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:19.086150043 +0530 >>>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java 2020-04-06 00:19:18.670148453 +0530 >>>> @@ -1077,7 +1077,7 @@ >>>> * Start a new Process using an explicit array of redirects. >>>> * See {@link #start} for details of starting each Process. >>>> * >>>> - * @param redirect array of redirects for stdin, stdout, stderr >>>> + * @param redirects array of redirects for stdin, stdout, stderr >>>> * @return the new Process >>>> * @throws IOException if an I/O error occurs >>>> */ >>>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:20.050153727 +0530 >>>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java 2020-04-06 00:19:19.634152137 +0530 >>>> @@ -731,7 +731,7 @@ >>>> * Constructs an empty GregorianCalendar. >>>> * >>>> * @param zone the given time zone >>>> - * @param aLocale the given locale >>>> + * @param locale the given locale >>>> * @param flag the flag requesting an empty instance >>>> */ >>>> GregorianCalendar(TimeZone zone, Locale locale, boolean flag) { >>>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:21.042157520 +0530 >>>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java 2020-04-06 00:19:20.630155944 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2004, 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 >>>> @@ -316,7 +316,7 @@ >>>> * If the address already has a scope-id or if the address is not local, ipv6 >>>> * or link local, then the original address is returned. >>>> * >>>> - * @param addr >>>> + * @param address >>>> * @exception SocketException if the given ipv6 link local address is found >>>> * on more than one local interface >>>> * @return >>>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:22.266162200 +0530 >>>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java 2020-04-06 00:19:21.854160624 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2001, 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 >>>> @@ -208,7 +208,7 @@ >>>> * Use New to get new HttpsClient. This constructor is meant to be >>>> * used only by New method. New properly checks for URL spoofing. >>>> * >>>> - * @param URL https URL with which a connection must be established >>>> + * @param url https URL with which a connection must be established >>>> */ >>>> private HttpsClient(SSLSocketFactory sf, URL url) >>>> throws IOException >>>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.502166928 +0530 >>>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java 2020-04-06 00:19:23.082165322 +0530 >>>> @@ -321,7 +321,7 @@ >>>> /** >>>> * Loads the provider with the specified class name. >>>> * >>>> - * @param name the name of the provider >>>> + * @param pn the name of the provider >>>> * @return the Provider, or null if it cannot be found or loaded >>>> * @throws ProviderException all other exceptions are ignored >>>> */ >>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.446170540 +0530 >>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java 2020-04-06 00:19:24.034168963 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2000, 2012, 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 >>>> @@ -72,7 +72,7 @@ >>>> * Constructor that initializes the input parameters. >>>> * >>>> * @param anchor the anchor selected to validate the target certificate >>>> - * @param testDate the time for which the validity of the certificate >>>> + * @param date the time for which the validity of the certificate >>>> * should be determined >>>> * @param sigProvider the name of the signature provider >>>> * @param sigOnly true if only signature checking is to be done; >>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:25.394174168 +0530 >>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java 2020-04-06 00:19:24.982172591 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2000, 2018, 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 >>>> @@ -69,7 +69,7 @@ >>>> /** >>>> * Initialize the builder with the input parameters. >>>> * >>>> - * @param params the parameter set used to build a certification path >>>> + * @param buildParams the parameter set used to build a certification path >>>> */ >>>> Builder(BuilderParams buildParams) { >>>> this.buildParams = buildParams; >>>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.618178853 +0530 >>>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java 2020-04-06 00:19:26.210177291 +0530 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1999, 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 >>>> @@ -111,7 +111,7 @@ >>>> * @param ruleFile the name of the rule data file >>>> * @param ruleData the rule data loaded from the rule data file >>>> * @param dictionaryFile the name of the dictionary file >>>> - * @param dictionartData the dictionary data loaded from the dictionary file >>>> + * @param dictionaryData the dictionary data loaded from the dictionary file >>>> * @throws MissingResourceException if rule data or dictionary initialization failed >>>> */ >>>> public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData, >>>> >>>> >>>>>> On 6 Apr 2020, at 17:07, Vipin Sharma wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net >>>>>> Please suggest if there is any way I can create my user id to upload this patch. >>>>>> >>>>>> This is ~300 line patch file. >>>>>> >>>>>> Regards, >>>>>> Vipin >>>>>> >>>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes wrote: >>>>>>> >>>>>>> Hi Vipin, >>>>>>> >>>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote: >>>>>>>> Hi, >>>>>>>> I have fixed a few warnings where the method parameter name is different in >>>>>>>> code and Javadoc, need a sponsor for this patch. >>>>>>>> Webrev is available at >>>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e >>>>>>> >>>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Regards, >>>>>>>> Vipin >>>>>> >>>>> >>>> Thanks, >>>> Vipin > From david.holmes at oracle.com Thu Apr 9 00:35:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Apr 2020 10:35:27 +1000 Subject: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file In-Reply-To: References: <428675e0-f09c-ac6b-f5ec-afc4190a6b45@oracle.com> <16A3371B-EABC-4955-902C-78EB079094DB@oracle.com> Message-ID: <23e587ec-4673-e0a2-3345-f0420c9b3eeb@oracle.com> Looks good. Thanks, David On 9/04/2020 3:27 am, Evgeny Nikitin wrote: > Thanks to Igor Ignatyev, a new version is available at > > http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.02 > > Regards, > Evgeny. > > > On 2020-04-08 17:19, Igor Ignatev wrote: >> You can use %n in printf to get a system-specific newline. >> >> ? Igor >> >>> On Apr 8, 2020, at 8:12 AM, Evgeny Nikitin >>> wrote: >>> >>> ?Hi David, >>> >>>> ? > You can use printf rather than making a separate call to format. >>>> Good point, I've missed that method. I'll fix it and ask Igor to change >>>> the webrev. >>> >>> I finally decided to leave it as it is now, since printf doesn't add >>> a newline and System.lineSeparator() is not shorter than >>> String.format() :). Please let me know if you disagree. >>> >>> Best regards, >>> Evgeny. >>> >>> >>>> On 2020-04-07 16:09, Evgeny Nikitin wrote: >>>> Hi David, >>>>> why did you introduce a new block scope? >>>> To separate the action block from the other code. "A Poor/lazy man's >>>> method". I've preferred to lay it out this way because it makes the >>>> code more compact and easy to read (as opposing to looking for a >>>> only-once used method in some other part of the file) and due to the >>>> confusing name of OutputAnalyzer type (which I need as a storage for >>>> output, not as some analyzer). Creating a method with OutputAnalyzer >>>> as a parameter would make this method's purpose even more confusing. >>>>> You can use printf rather than making a separate call to format. >>>> Good point, I've missed that method. I'll fix it and ask Igor to >>>> change the webrev. >>>> Regards, >>>> Evgeny. >>>>> On 2020-04-07 14:50, David Holmes wrote: >>>>> Hi Evgeny, >>>>> >>>>> On 7/04/2020 6:33 pm, Evgeny Nikitin wrote: >>>>>> Hi David, >>>>>> >>>>>>> I'm not at all sure this is generally what we want for every >>>>>>> single test that uses ProcessTools! But I'm willing it to see it >>>>>>> trialed. >>>>>> >>>>>> Well, it's mostly used for test VM runs. In runs I performed >>>>>> (artificial "failures" included) the amounts of output were very >>>>>> small. >>>>>> >>>>>>> Please run full tier testing at least to tier 6 and ideally >>>>>>> beyond before pushing this. There are potential implications for >>>>>>> temporary (and more permanent) disk usage as well as additional >>>>>>> time needed to write files out to disk. (Hopefully these are >>>>>>> generally small enough that this doesn't make a noticeable >>>>>>> difference.) >>>>>> Done, thanks for suggestion. The additional runs showed no problems. >>>>> >>>>> Good to know - thanks. >>>>> >>>>>> I've provided Igor with a slightly modified version (Added >>>>>> notification about the output file into the main test's log). >>>>>> Please review: >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.01/ >>>>> >>>>> A couple of minor nits: >>>>> >>>>> ? 397???????????? { >>>>> >>>>> why did you introduce a new block scope? >>>>> >>>>> ? 404???????????????? System.out.println(String.format( >>>>> >>>>> You can use printf rather than making a separate call to format. >>>>> >>>>> No need to see any update if you chose to make it. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Best Regards, >>>>>> >>>>>> Evgeny. >>>>>> >>>>>> On 2020-04-02 02:07, David Holmes wrote: >>>>>>> Thanks for sharing this Igor! >>>>>>> >>>>>>> I'm not at all sure this is generally what we want for every >>>>>>> single test that uses ProcessTools! But I'm willing it to see it >>>>>>> trialed. >>>>>>> >>>>>>> Evgeny: Please run full tier testing at least to tier 6 and >>>>>>> ideally beyond before pushing this. There are potential >>>>>>> implications for temporary (and more permanent) disk usage as >>>>>>> well as additional time needed to write files out to disk. >>>>>>> (Hopefully these are generally small enough that this doesn't >>>>>>> make a noticeable difference.) >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 2/04/2020 5:13 am, Igor Ignatyev wrote: >>>>>>>> Hi Evgeny, >>>>>>>> >>>>>>>> (widening the audience, given this affects not just hotspot >>>>>>>> compiler, but hotspot tests as well as core libs tests in general) >>>>>>>> >>>>>>>> overall that looks good to me. one suggestion, for the ease of >>>>>>>> failure analysis it might be worth to print out the names of >>>>>>>> created files, although this might potentially clutter the >>>>>>>> output, I don't think it'll be a problem given we already print >>>>>>>> out things like 'Gathering output for process ...' , 'Waiting >>>>>>>> for completion...' in LazyOutputBuffer. >>>>>>>> >>>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>>>>>> macosx-x64, sparcv9). >>>>>>>> this doesn't include any of hotspot tiers, could you please also >>>>>>>> run hs-tier1--4? >>>>>>>> // you can use tierN jobs which include both jdk and hs parts. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -- Igor >>>>>>>> >>>>>>>>> On Mar 30, 2020, at 3:55 AM, Evgeny Nikitin >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8174768 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/enikitin/8174768/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> The bug had been created as a request to simplify investigation >>>>>>>>> for compiler control tests failures. >>>>>>>>> I found the functionality pretty generic and useful and made >>>>>>>>> ProcessTools dump output as well as some diagnostic information >>>>>>>>> for every executed process into a separate file. >>>>>>>>> The diagnostic information contains cmdline, exit code, stdout >>>>>>>>> and stderr. The output files are named like >>>>>>>>> 'pid--output.log'. >>>>>>>>> >>>>>>>>> The change has been tested via a mach5 test runs (jdk-tier1 >>>>>>>>> through 4) on the 4 common platforms (linux-x64, windows-x64, >>>>>>>>> macosx-x64, sparcv9). >>>>>>>>> >>>>>>>>> Please review, >>>>>>>>> /Evgeny Nikitin. >>>>>>>> >> From naoto.sato at oracle.com Thu Apr 9 00:44:29 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 8 Apr 2020 17:44:29 -0700 Subject: RFR [15/java.xml] 8237187 Obsolete references to java.sun.com In-Reply-To: <1BF26614-C5B8-46EE-9345-26D6875C0F59@oracle.com> References: <1BF26614-C5B8-46EE-9345-26D6875C0F59@oracle.com> Message-ID: <8d467c79-e480-869b-f738-3228fe9ec9cc@oracle.com> ++1 Naoto On 4/8/20 4:34 PM, Lance Andersen wrote: > +1 > >> On Apr 8, 2020, at 7:28 PM, Joe Wang wrote: >> >> Please review a doc-only change to replace links to sun.com with ones to oracle.com. Only material changes were the two sun.com links, others format, e.g. moving the anchor brackets to within one line. >> >> --- a/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java >> +++ b/src/java.base/share/classes/jdk/internal/util/xml/impl/ParserSAX.java >> @@ -40,14 +40,14 @@ >> >> /** >> * XML non-validating push parser. >> - * >> - * This non-validating parser conforms to > - * >Extensible Markup Language (XML) 1.0 and > - * href="http://www.w3.org/TR/REC-xml-names" >"Namespaces in XML" >> - * specifications. The API supported by the parser are > - * href="http://java.sun.com/aboutJava/communityprocess/final/jsr030/index.html">CLDC >> - * 1.0 and JSR-280, a >> - * JavaME subset of JAXP >> + *

tags. It looks nice in source, but it won't be like that in the output. (For better or worse, this is not Markdown.) That is intentional; I prefer to separate the lines with white-space. > > 2. @implSpec for AnnotatedElement.isAnnotationPresent reads pretty unconventionally. There's nothing wrong with that. I simply wonder if there are any reasons why you picked that wording as opposed to the typical "The default implementation calls/returns/performs/etc. ..."? Also, there's a typo: "the the". Good point; changed to the conventional "The default implementation returns \$EXPRESSION." > > 3. Since we are in this area, would you care to fix a couple of typos? Why not :-) > > diff -r 193e4179def8 src/java.base/share/classes/java/lang/reflect/Modifier.java > --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java Wed Apr 08 22:58:42 2020 -0700 > +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java Thu Apr 09 11:28:32 2020 +0100 > @@ -377,7 +377,7 @@ > > /** > * The Java source modifiers that can be applied to a method. > - * @jls8.4.3 Method Modifiers > + * @jls 8.4.3 Method Modifiers > */ > private static final int METHOD_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | > @@ -400,9 +400,6 @@ > private static final int PARAMETER_MODIFIERS = > Modifier.FINAL; > > - /** > - * > - */ > static final int ACCESS_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE; Thanks for the review, -Joe From huizhe.wang at oracle.com Thu Apr 9 21:28:40 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 9 Apr 2020 14:28:40 -0700 Subject: RFR [15/java.xml] 8242470 : Upgrade Xerces to Version 2.12.1 Message-ID: <78f8b40f-017a-3b72-8996-2e0ca88c73ee@oracle.com> Please review an update to Xerces 2.12.1. Xerces 2.12.1 was a bug fix release. Bugs in the release were either already in the JDK or not applicable. This patch therefore includes only an update to the md file. --- a/src/java.xml/share/legal/xerces.md +++ b/src/java.xml/share/legal/xerces.md @@ -1,4 +1,4 @@ -## Apache Xerces v2.12.0 +## Apache Xerces v2.12.1 ?### Apache Xerces Notice ?

```@@ -8,9 +8,11 @@
=========================================================================

???? Apache Xerces Java
-??? Copyright 1999-2018 The Apache Software Foundation
+??? Copyright 1999-2020 The Apache Software Foundation
+
???? This product includes software developed at
???? The Apache Software Foundation (http://www.apache.org/).
+
???? Portions of this software were originally based on the following:
???? - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
???? - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.

Thanks,
Joe

From lance.andersen at oracle.com  Thu Apr  9 21:32:35 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 9 Apr 2020 17:32:35 -0400
Subject: RFR [15/java.xml] 8242470 : Upgrade Xerces to Version 2.12.1
References: <78f8b40f-017a-3b72-8996-2e0ca88c73ee@oracle.com>
Message-ID: <51BD5834-0E13-40FF-8FFF-A1736B14BF74@oracle.com>

+1

> On Apr 9, 2020, at 5:28 PM, Joe Wang  wrote:
>
> Please review an update to Xerces 2.12.1. Xerces 2.12.1 was a bug fix release. Bugs in the release were either already in the JDK or not applicable. This patch therefore includes only an update to the md file.
>
> --- a/src/java.xml/share/legal/xerces.md
> +++ b/src/java.xml/share/legal/xerces.md
> @@ -1,4 +1,4 @@
> -## Apache Xerces v2.12.0
> +## Apache Xerces v2.12.1
>
>  ### Apache Xerces Notice
>  > @@ -8,9 +8,11 @@
> =========================================================================
>
>      Apache Xerces Java
> -    Copyright 1999-2018 The Apache Software Foundation
> +    Copyright 1999-2020 The Apache Software Foundation
> +
>      This product includes software developed at
>      The Apache Software Foundation (http://www.apache.org/).
> +
>      Portions of this software were originally based on the following:
>      - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
>      - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
>
>
> 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 naoto.sato at oracle.com  Thu Apr  9 21:32:50 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 9 Apr 2020 14:32:50 -0700
Subject: RFR [15/java.xml] 8242470 : Upgrade Xerces to Version 2.12.1
References: <78f8b40f-017a-3b72-8996-2e0ca88c73ee@oracle.com>
Message-ID: <95df5ddd-bf83-1027-a56f-0895811c651e@oracle.com>

+1

Naoto

On 4/9/20 2:28 PM, Joe Wang wrote:
> Please review an update to Xerces 2.12.1. Xerces 2.12.1 was a bug fix
> release. Bugs in the release were either already in the JDK or not
> applicable. This patch therefore includes only an update to the md file.
>
> --- a/src/java.xml/share/legal/xerces.md
> +++ b/src/java.xml/share/legal/xerces.md
> @@ -1,4 +1,4 @@
> -## Apache Xerces v2.12.0
> +## Apache Xerces v2.12.1
>
>  ?### Apache Xerces Notice
>  ?> @@ -8,9 +8,11 @@
> =========================================================================
>
>  ???? Apache Xerces Java
> -??? Copyright 1999-2018 The Apache Software Foundation
> +??? Copyright 1999-2020 The Apache Software Foundation
> +
>  ???? This product includes software developed at
>  ???? The Apache Software Foundation (http://www.apache.org/).
> +
>  ???? Portions of this software were originally based on the following:
>  ???? - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
>  ???? - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
>
>
> Thanks,
> Joe

From stuart.marks at oracle.com  Fri Apr 10 02:52:57 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 9 Apr 2020 19:52:57 -0700
Subject: RFR 15 8242327: List spec should state that unmodifiable lists
implement RandomAccess
References:
<18E51A3D-BEE9-40DD-B0D2-01055D18EECF@oracle.com>
Message-ID: <53af21ee-aa9e-40a8-f2c8-2311a035889c@oracle.com>

Thanks Lance.

reference form of a javadoc link. Revised patch below. Also, could you review
the CSR?

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

Thanks,

s'marks

# HG changeset patch
# User smarks
# Date 1586486847 25200
#      Thu Apr 09 19:47:27 2020 -0700
# Node ID 45a22ec2df1a3738d241d82c375507bf4aeb3d1b
# Parent  46108b5b69d92dd424b73b828454849c397509cb
8242327: List spec should state that unmodifiable lists implement RandomAccess
Reviewed-by: XXX

diff -r 46108b5b69d9 -r 45a22ec2df1a src/java.base/share/classes/java/util/List.java
--- a/src/java.base/share/classes/java/util/List.java	Tue Apr 07 16:31:46 2020 -0700
+++ b/src/java.base/share/classes/java/util/List.java	Thu Apr 09 19:47:27 2020 -0700
@@ -104,6 +104,8 @@
* They are serializable if all elements are serializable.
* The order of elements in the list is the same as the order of the
* provided arguments, or of the elements in the provided array.
+ * The lists and their {@link #subList(int, int) subList} views implement the
* They are value-based.
* Callers should make no assumptions about the identity of the returned
instances.
* Factories are free to create new instances or reuse existing ones. Therefore,

On 4/8/20 2:33 PM, Lance Andersen wrote:
> Hi Stuart,
>
> This looks good
>
>> On Apr 8, 2020, at 5:01 PM, Stuart Marks > > wrote:
>>
>> Hi all,
>>
>> Please review this small change to the List interface that specifies that
>> unmodifiable lists (returned by List.of et al) implement the RandomAccess
>> marker interface. In fact, they already do; the intent of this section was to
>> specify the user-visible characteristics of such lists, but this particular
>> characteristic was accidentally omitted.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8242327
>>
>> Patch below. I'll follow up with a CSR request.
>>
>> Thanks,
>>
>> s'marks

From lance.andersen at oracle.com  Fri Apr 10 11:58:34 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 10 Apr 2020 07:58:34 -0400
Subject: RFR 15 8242327: List spec should state that unmodifiable lists
implement RandomAccess
References:
<18E51A3D-BEE9-40DD-B0D2-01055D18EECF@oracle.com>
<53af21ee-aa9e-40a8-f2c8-2311a035889c@oracle.com>
Message-ID:

Hi Stuart

Looks good and I reviewed the CSR this morning also

Best
Lance

> On Apr 9, 2020, at 10:52 PM, Stuart Marks  wrote:
>
> Thanks Lance.
>
> Upon advice from Pavel Rappo, I've adjusted the link markup to use the full reference form of a javadoc link. Revised patch below. Also, could you review the CSR?
>
> https://bugs.openjdk.java.net/browse/JDK-8242406
>
> Thanks,
>
> s'marks
>
>
>
> # HG changeset patch
> # User smarks
> # Date 1586486847 25200
> #      Thu Apr 09 19:47:27 2020 -0700
> # Node ID 45a22ec2df1a3738d241d82c375507bf4aeb3d1b
> # Parent  46108b5b69d92dd424b73b828454849c397509cb
> 8242327: List spec should state that unmodifiable lists implement RandomAccess
> Reviewed-by: XXX
>
> diff -r 46108b5b69d9 -r 45a22ec2df1a src/java.base/share/classes/java/util/List.java
> --- a/src/java.base/share/classes/java/util/List.java	Tue Apr 07 16:31:46 2020 -0700
> +++ b/src/java.base/share/classes/java/util/List.java	Thu Apr 09 19:47:27 2020 -0700
> @@ -104,6 +104,8 @@
>  * They are serializable if all elements are serializable.
>  * The order of elements in the list is the same as the order of the
>  * provided arguments, or of the elements in the provided array.
> + * The lists and their {@link #subList(int, int) subList} views implement the
> + * {@link RandomAccess} interface.
>  * They are value-based.
>  * Callers should make no assumptions about the identity of the returned instances.
>  * Factories are free to create new instances or reuse existing ones. Therefore,
>
>
>
>
> On 4/8/20 2:33 PM, Lance Andersen wrote:
>> Hi Stuart,
>> This looks good
>>> On Apr 8, 2020, at 5:01 PM, Stuart Marks > wrote:
>>>
>>> Hi all,
>>>
>>> Please review this small change to the List interface that specifies that unmodifiable lists (returned by List.of et al) implement the RandomAccess marker interface. In fact, they already do; the intent of this section was to specify the user-visible characteristics of such lists, but this particular characteristic was accidentally omitted.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8242327
>>>
>>> Patch below. I'll follow up with a CSR request.
>>>
>>> Thanks,
>>>
>>> s'marks
>

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 suenaga at oss.nttdata.com  Fri Apr 10 14:29:09 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 10 Apr 2020 23:29:09 +0900
Subject: RFR: 8242283: Can't start JVM when java home path includes non-ASCII
character
Message-ID: <94ea9f9f-75a9-f9a4-da74-8c583d62b1f2@oss.nttdata.com>

Hi all,

JBS: https://bugs.openjdk.java.net/browse/JDK-8242283
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242283/webrev.00/

After JDK-8240197 and JDK-8240725, java cannot start when java home path includes non-ASCII character e.g. Japanese Kanji.

But this change would not resolve in all cases. For example, Japanese encoded pathname cannot be recognized under the English system locale. It is (implicitly) described in the spec for JNI_CreateJavaVM().

https://docs.oracle.com/en/java/javase/14/docs/specs/jni/invocation.html#jni_createjavavm:
```
char *optionString; /* the option as a string in the default platform encoding */
```

Thanks,

Yasumasa

From naoto.sato at oracle.com  Fri Apr 10 17:17:51 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Apr 2020 10:17:51 -0700
Subject: RFR: 8242283: Can't start JVM when java home path includes
non-ASCII character
References: <94ea9f9f-75a9-f9a4-da74-8c583d62b1f2@oss.nttdata.com>
Message-ID:

Suenaga-san,

Looks good to me. Please add noreg-hard if you are not planning to
provide test cases. Thank you for fixing this issue.

Naoto

On 4/10/20 7:29 AM, Yasumasa Suenaga wrote:
> Hi all,
>
>
>  ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242283
>  ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242283/webrev.00/
>
> After JDK-8240197 and JDK-8240725, java cannot start when java home path
> includes non-ASCII character e.g. Japanese Kanji.
> CP_THREAD_ACP to CP_ACP in MultiByteToWideChar() because CP_ACP works
>
> But this change would not resolve in all cases. For example, Japanese
> encoded pathname cannot be recognized under the English system locale.
> It is (implicitly) described in the spec for JNI_CreateJavaVM().
>
> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/invocation.html#jni_createjavavm:
>
> ```
>  ??? char *optionString; /* the option as a string in the default
> platform encoding */
> ```
>
>
> Thanks,
>
> Yasumasa

From Roger.Riggs at oracle.com  Fri Apr 10 18:25:48 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 10 Apr 2020 14:25:48 -0400
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
Message-ID: <8b2b876d-f0a4-6cbb-4418-83e30b8b8c99@oracle.com>

Hi,

Created an entry to track the enhancement:
??? https://bugs.openjdk.java.net/browse/JDK-8242504

Changes affecting the Core Libraries APIs also need be reviewed by
core-libs-dev.

Regards, Roger

On 4/10/20 1:03 PM, Mark Kralj-Taylor wrote:
> I'd like to help Java Clock.systemUTC() expose nanosecond precision
> UTC realtime (wall-time) clock, where OS and CPU allow.
>
> Please let me know if this would be acceptable for OpenJDK, and what
> next steps I can take to progress this towards submitting a patch.
> - I have some time at the moment. I've signed the OCA, but don't have
> login to the OpenJDK bugtracker, if you want me to submit a proper hg
> patch there.
> - This mail includes the patch as `hg diff` outputs together with JMH
> and test output from it.
>
> The patch here improves the existing API java.time.Instant.now() i.e.
> Clock.systemUTC().instant() on Linux to return Linux
> clock_gettime(CLOCK_REALTIME) which can be nanosecond precision (and
> very low cost, se JMH results) when Linux has a suitable clocksource
> (tsc).
>
> change semantics of the existing Clock.systemUTC().instant() API which
>
> Clock.systemUTC().instant() is backed by Hotspot
> os::javaTimeSystemUTC, which can be updated to call higher precision
> OS real-time clock API when available (and has similar performance),
> rather than the current code that multiplies microseconds from
> gettimeofday() by 1000 to get nanoseconds.
>
> In Linux this means calling the Posix clock_gettime(CLOCK_REALTIME)
> API instead of the older gettimeofday() whose output is limited to
> microsecond precision. On a suitable CPU Linux can back
> clock_gettime(CLOCK_REALTIME) with a nanosecond precision CPU TSC
> clocksource. Whereas the output of gettimeofday() is limited to
> microsecond precision (even when Linux is using a higher precision
> clocksource).
>
> A similar change could be made for other OS that offer a performant
> API to get hi-precision wall-time.
> - OSX: Unfortunately on my Mac I found that
> clock_gettime(CLOCK_REALTIME) is limited to microseconds precision
> (source shows it calling gettimeofday() and multiplying by 1000 - see
> note on recent Linux change to discourage that). An alternate approach
> that did get nanosecond precision wall-time was too slow to be of
> interest (>900ns!): Calling OSX host_get_clock_service CALENDAR_CLOCK
> in JVM init, then clock_get_time(clockPortFromPrev,...).
> - Windows: GetSystemTimePreciseAsFileTime looks promising. See
> https://docs.microsoft.com/en-gb/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
> . Unfortunately I don't have access to a Windows machine to try this
> on, but if you are interested in the Linux patch I could buy windows
> for a laptop we have to see how  fares in JMH.
>
> Details, patch and JMH / test outputs follow below.
> Thanks,
> Mark
>
> -----------------
>
> # RATIONAL: Why does Java need nanosecond precision real-time clock?
>
> Like many others working on lower-latency Java systems running on
> Linux I have been using JNI to call clock_gettime(CLOCK_REALTIME, ...)
> to do this for years. Hi-precision (nanosecond) UTC timestamps have
> been essential in understanding and improving end-to-end latency and
> performance of multi-process systems. Including nanosecond wall-time
> after-receive and before-send timestamps in messages sent over the
> wire (or shared memory, or in stored events) gives tremendous
> transparency on latency in multi-process and multi-host event
> processing and workflows.
>
> Java has evolved to remove more and more common cases for JNI. Getting
> a nanosecond real-time clock timestamp feels a good candidate for that
> process, especially because it looks like hi-precision real-time UTC
> clock APIs are common in the minimum OS versions Java is built for
> (even if some OS still give microsecond precision wall-time behind an
> API that returns nanoseconds - as OSX 10.15 did for me - built with
> XCode 10.1 as per JDK docs.
>
> Timestamps from a monotonic clock can only be compared within the same
> host, or for Java's System.nanoTime() within the same Java process.
> This is very useful, but doesn't help with multi-process, multi-host,
> multi-language use-cases.
>
> Realtime (wall-time) UTC clock timestamps are useful because they can
> be compared between different processes, possibly running on a
> different host, as well as within a process. Within the same
> data-centre latency between processes is typically well under a
> millisecond for UDP / multicast between hosts. Latency can be
> sub-microsecond for shared-memory between processes on the same host.
>
> A monotonic clock is often favoured for timing latency, because
> real-time clocks on different hosts are subject to slewing and
> stepping. Clock-sync technologies drastically reduce impact of these
> on a host and also time offsets between different hosts (especially in
> the same data centre). For high event rate systems you can look at
> latency as percentiles over time-windows. With many time-windows you
> get an idea of clock sync quality because you see the distribution
> move when you look at a time-series of percentiles for time-windows if
> different hosts have different clock stepping time synchronisation.
>
> -----------------
>
> # IS THIS A SAFE CHANGE for the JDK?
>
> It makes no change to semantics of Clock.systemUTC(), whose JavaDoc
> says: "This clock is based on the best available system clock. This
> may use System.currentTimeMillis(), or a higher resolution clock if
> one is available.".
>
> Because there is no new JDK API, nor change in API semantics. This
> enhancement can be made on an OS by OS basis.
>
> -----------------
>
> # IS THIS A SAFE CHANGE for Linux?
>
> The "clock_gettime(3) - Linux man page" says: "All implementations
> support the system-wide realtime clock, which is identified by
> CLOCK_REALTIME. Its time represents seconds and nanoseconds since the
> Epoch.". See: https://linux.die.net/man/3/clock_gettime
>
> FYI Some older Linux ports used to implement
> clock_gettime(CLOCK_REALTIME,) by calling gettimeofday() and
> multiplying by 1000. This would be fine with the patch proposed, but
> means that resolution would be limited to microseconds by the OS. A
> Linux change 6 months ago has discouraged that in ports: "Use
> clock_gettime to implement gettimeofday"
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
> .
>
> -----------------
>
> # Related OpenJDK BugTrackers
>
> Comments on these enhancements requests suggest some interest in
> calling Linux clock_gettime(REALTIME) intsead of gettimeofday().
> Although the enhancement requests themselves are not the same as this
> mail, which asks to enhance an existing API, within its existing
> semantics.
> - JDK-6709908
> - JDK-8185891
>
> Since Java 9 Clock.systemUTC() has up to microsecond resolution on Linux
> - JDK-8068730 Increase the precision of the implementation of
> java.time.Clock.systemUTC()
>
> -----------------
>
> # POSSIBLE FOLLOW ON (that is NOT part of the patch or proposal discussed here)
>
> A possible follow-on would be to add a JDK API to give more direct
> (lower cost) access to a hi-precision timestamp as a nanoseconds since
> UTC epoc in a long. For example System.curretTimeNanos(). This would
> be different to the proposal above in that its range would be limited
> to year 2262 for a unsigned long, which is more than 200 years in the
> future, but less than Instant.MAX. A JMH benchmarks with
> systemTimeNanos() as an intrinsic (following the style of
> currentTimeMillis) demonstrated that this is attractive, with similar
> cost to System.currentTimeMillis()/nanoTime(), so better than
> Instant.now() or JNI that I used. But initially I'd rather focus on
> improving Java without adding any new APIs, or discussing if ~200
> years is enough of a range.
>
> -----------------
>
> # PATCHES to Hotspot, tests and output of those tests
>
> ## PATCH to hotspot/os/linux/os_linux.cpp
>
> This patch changes both os::javaTimeMillis and os::javaTimeSystemUTC
> to call clock_gettime(CLOCK_REALTIME, ..) instead of gettimeofday().
> This keeps the 2 methods obviously consistent, and avoids someone
> reading the code having questions on the consistency of different
> Linux APIs. Results form JMH benchmark (see below) show this is ok.
>
> This seams consistent with direction being taken by Linux, based on
> change: "Use clock_gettime to implement gettimeofday" at
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
>
> ```
> diff --git a/src/hotspot/os/linux/os_linux.cpp
> b/src/hotspot/os/linux/os_linux.cpp
> --- a/src/hotspot/os/linux/os_linux.cpp
> +++ b/src/hotspot/os/linux/os_linux.cpp
> @@ -88,6 +88,7 @@
> # include
> # include
> # include
> +# include
> # include
> # include
> # include
> @@ -1374,18 +1375,18 @@
> }
> jlong os::javaTimeMillis() {
> - timeval time;
> - int status = gettimeofday(&time, NULL);
> + timespec time;
> + int status = clock_gettime(CLOCK_REALTIME, &time);
> assert(status != -1, "linux error");
> - return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
> + return jlong(time.tv_sec) * 1000 + jlong(time.tv_nsec / 1000000);
> }
> void os::javaTimeSystemUTC(jlong &seconds, jlong &nanos) {
> - timeval time;
> - int status = gettimeofday(&time, NULL);
> + timespec time;
> + int status = clock_gettime(CLOCK_REALTIME, &time);
> assert(status != -1, "linux error");
> seconds = jlong(time.tv_sec);
> - nanos = jlong(time.tv_usec) * 1000;
> + nanos = jlong(time.tv_nsec);
> }
> ```
>
> ## PATCH to test/micro JMH benchmark to assess impact of change on
> Instant.now(), and show its performance relative to
> System.currentTimeMillis()/nanoTime().
>
> Where would the best place be to add an Instant.now() JMH bennchmark?
> - While I'd guess the convention is to follow the package of the API
> being benchmarked. I like that by putting benchmarks of system
> timestamping APIs in one class its easy and natural to spot them all
> and compare them. Could the benchmark be added here, then the class
> renamed to SystemTime.java to focus on benchmarking those features?
>
> ```
> diff --git a/test/micro/org/openjdk/bench/java/lang/Systems.java
> b/test/micro/org/openjdk/bench/java/lang/Systems.java
> --- a/test/micro/org/openjdk/bench/java/lang/Systems.java
> +++ b/test/micro/org/openjdk/bench/java/lang/Systems.java
> @@ -28,6 +28,7 @@
> import org.openjdk.jmh.annotations.OutputTimeUnit;
> import java.util.concurrent.TimeUnit;
> +import java.time.Instant;
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @@ -43,4 +44,9 @@
> return System.nanoTime();
> }
> + @Benchmark
> + public long instant_now_asEpocNanos() {
> + Instant now = Instant.now();
> + return now.getEpochSecond() * 1_000_000_000L + now.getNano();
> + }
> ```
>
> ### RESULTS from JDK Micro benchmark:
> Run on Linux with clocksource=tsc on a 3GHz Intel i5 CPU (see details below).
>
> `make test TEST="micro:java.lang.Systems"`
>
> WITH change to os_linux.cpp:
> ```
> Benchmark Mode Cnt Score Error Units
> Systems.currentTimeMillis avgt 25 19.190 ? 0.166 ns/op
> Systems.instant_now_asEpocNanos avgt 25 29.809 ? 0.191 ns/op
> Systems.nanoTime avgt 25 18.534 ? 0.024 ns/op
> ```
>
> WITHOUT change to os_linux.cpp: (but with the added JMH benchmark for
> purpose of comparison)
> ```
> Benchmark Mode Cnt Score Error Units
> Systems.currentTimeMillis avgt 25 19.013 ? 0.033 ns/op
> Systems.instant_now_asEpocNanos avgt 25 30.459 ? 0.017 ns/op
> Systems.nanoTime avgt 25 18.971 ? 0.053 ns/op
> ```
>
> ### Platform details:
> System: Linux (Ubuntu) running on Mac Mini 2018 3 GHz Intel i5
> ```
> \$ uname -a
> Linux MacMiniLinux 5.3.0-42-generic #34-Ubuntu SMP Fri Feb 28 05:49:40
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> \$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
> \$ ldd --version
> ldd (Ubuntu GLIBC 2.30-0ubuntu2.1) 2.30
>
> \$ lscpu | egrep '(Model name|CPU.s.:)'
> CPU(s): 6
> Model name: Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
> NUMA node0 CPU(s): 0-5
>
> \$ lscpu | grep Flags | sed 's@ @\n at g' | grep -i tsc
> tsc
> rdtscp
> constant_tsc
> nonstop_tsc
> ```
>
> ## PATCH to JDK test code - that logs realtime clock precision:
>
> ```
> diff --git a/test/jdk/java/time/test/java/time/TestClock_System.java
> b/test/jdk/java/time/test/java/time/TestClock_System.java
> --- a/test/jdk/java/time/test/java/time/TestClock_System.java
> +++ b/test/jdk/java/time/test/java/time/TestClock_System.java
> @@ -177,7 +177,8 @@
> + formatTime("\n\thighest1", highest1));
> }
> - int count=0;
> + int count_betterThanMillisPrecision=0;
> + int count_betterThanMicrosPrecision=0;
> // let's preheat the system a bit:
> int lastNanos = 0;
> for (int i = 0; i < 1000 ; i++) {
> @@ -191,7 +192,10 @@
> lastNanos = nanos;
> if ((nanos % 1000000) > 0) {
> - count++; // we have micro seconds
> + count_betterThanMillisPrecision++; // we have microseconds
> + }
> + if ((nanos % 1000) > 0) {
> + count_betterThanMicrosPrecision++; // we have nanoseconds
> }
> if ((sysnan % 1000000) > 0) {
> throw new RuntimeException("Expected only millisecconds "
> @@ -200,10 +204,12 @@
> }
> }
> System.out.println("\nNumber of time stamps which had better than"
> - + " millisecond precision: "+count+"/"+1000);
> + + " millisecond precision: "+count_betterThanMillisPrecision+"/"+1000);
> + System.out.println("\nNumber of time stamps which had better than"
> + + " microsecond precision: "+count_betterThanMicrosPrecision+"/"+1000);
> System.out.println(formatTime("\nsystemUTC ", system1));
> System.out.println(formatTime("highestResolutionUTC ", highest1));
> - if (count == 0) {
> + if (count_betterThanMillisPrecision == 0) {
> System.err.println("Something is strange: no microsecond "
> + "precision with highestResolutionUTC?");
> throw new RuntimeException("Micro second preccision not reached");
> ```
>
> ### OUTPUT of JDK Test logs observed clock precision
>
> Extract of test log when test patch run on same host as JMH below.
> Shows nanosecond precision (`999/1000 better than microsecond`).
>
> `make test TEST="jtreg:test/jdk/java/time/test/java/time/TestClock_System.java"
> JTREG="VERBOSE=all"`
>
> ```
> Number of time stamps which had better than millisecond precision: 1000/1000
>
> Number of time stamps which had better than microsecond precision: 999/1000
>
> systemUTC : 2020-04-03T23:14:12.276Z - seconds: 1585955652, nanos: 276000000
> highestResolutionUTC : 2020-04-03T23:14:12.276472680Z - seconds:
> 1585955652, nanos: 276472680
> ```

From igor.ignatyev at oracle.com  Fri Apr 10 18:44:08 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 10 Apr 2020 11:44:08 -0700
Subject: RFR 15 8242462: Residual Cleanup of rmic removal
References: <90bb7028-922a-a322-a2cf-844d43424b18@oracle.com>
Message-ID:

Hi Roger,

removal of applications/ctw/modules/jdk_rmic.java and changes in doc (assuming .html was generated from .md) look good to me.

adding hotspot-runtime alias to bring attention of runtime team. I'm not sure who are the right people to review bin/unshuffle_list.txt though,.. build team (cc'ed them)?

Cheers,
-- Igor

> On Apr 9, 2020, at 6:48 AM, Roger Riggs  wrote:
>
> Please review a few cleanups I missed on the removal of rmic.
> I didn't get a reply on the changes to the hotspot (cds) tests.
> (I did get an ok on the javadoc changes)
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc-1/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8242462
>
> Thanks, Roger
>

From erik.joelsson at oracle.com  Fri Apr 10 18:52:18 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 10 Apr 2020 11:52:18 -0700
Subject: RFR 15 8242462: Residual Cleanup of rmic removal
References: <90bb7028-922a-a322-a2cf-844d43424b18@oracle.com>

Message-ID: <740845b0-9ec5-dced-982d-d97fab60993a@oracle.com>

unshuffle_list.txt looks good to me.

/Erik

On 2020-04-10 11:44, Igor Ignatyev wrote:
> Hi Roger,
>
> removal of applications/ctw/modules/jdk_rmic.java and changes in doc (assuming .html was generated from .md) look good to me.
>
> adding hotspot-runtime alias to bring attention of runtime team. I'm not sure who are the right people to review bin/unshuffle_list.txt though,.. build team (cc'ed them)?
>
> Cheers,
> -- Igor
>
>> On Apr 9, 2020, at 6:48 AM, Roger Riggs  wrote:
>>
>> Please review a few cleanups I missed on the removal of rmic.
>> I didn't get a reply on the changes to the hotspot (cds) tests.
>> (I did get an ok on the javadoc changes)
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc-1/
>>
>> Issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8242462
>>
>> Thanks, Roger
>>

From eirbjo at gmail.com  Fri Apr 10 18:59:06 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 10 Apr 2020 20:59:06 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
Message-ID:

I recently needed to re-implement multi-release lookup logic for a
[1]

It occurred to me that JarFile.getVersionedEntry checks _every_ version
between 8 and the runtime version when looking up paths.

Since META-INF/versions will probably be sparsely populated, I'm wondering
if something could be done to avoid checking 20 different paths in OpenJDK
28.

Perhaps scanning META-INF/versions once when opening the file could work,
then only check existing versions in getVersionedEntry?

Maybe a premature optimization today, but with the new release cadence,
this problem is going to surface at some point in the future, right?

[1]
https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html

Eirik.

From mikhailo.seledtsov at oracle.com  Fri Apr 10 19:28:05 2020
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Fri, 10 Apr 2020 12:28:05 -0700
Subject: RFR 15 8242462: Residual Cleanup of rmic removal
References: <90bb7028-922a-a322-a2cf-844d43424b18@oracle.com>

Message-ID:

Runtime test changes look good to me,

Misha

On 4/10/20 11:44 AM, Igor Ignatyev wrote:
> Hi Roger,
>
> removal of applications/ctw/modules/jdk_rmic.java and changes in doc (assuming .html was generated from .md) look good to me.
>
> adding hotspot-runtime alias to bring attention of runtime team. I'm not sure who are the right people to review bin/unshuffle_list.txt though,.. build team (cc'ed them)?
>
> Cheers,
> -- Igor
>
>> On Apr 9, 2020, at 6:48 AM, Roger Riggs  wrote:
>>
>> Please review a few cleanups I missed on the removal of rmic.
>> I didn't get a reply on the changes to the hotspot (cds) tests.
>> (I did get an ok on the javadoc changes)
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-remove-rmic-8225319-misc-1/
>>
>> Issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8242462
>>
>> Thanks, Roger
>>

From lance.andersen at oracle.com  Fri Apr 10 20:55:58 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 10 Apr 2020 16:55:58 -0400
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
Message-ID: <5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Hi Eric

Feel free to enter a feature request and better yet propose a fix :-)

Have a good weekend!

Best
Lance

> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
>
> I recently needed to re-implement multi-release lookup logic for a
> [1]
>
> It occurred to me that JarFile.getVersionedEntry checks _every_ version
> between 8 and the runtime version when looking up paths.
>
> Since META-INF/versions will probably be sparsely populated, I'm wondering
> if something could be done to avoid checking 20 different paths in OpenJDK
> 28.
>
> Perhaps scanning META-INF/versions once when opening the file could work,
> then only check existing versions in getVersionedEntry?
>
> Maybe a premature optimization today, but with the new release cadence,
> this problem is going to surface at some point in the future, right?
>
> [1]
> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>
> Eirik.

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  Fri Apr 10 23:45:27 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Apr 2020 16:45:27 -0700 (PDT)
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
Message-ID: <0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>

Hi Mark,

Thanks for the very detailed proposal and write up!

It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and currentTimeMillis() have to use the
same time base, and currentTimeMillis() has to use gettimeofday(). I
thought this cross-dependency was documented somewhere but can't find it
right now. If gettimeofday and clock_gettime(CLOCK_REALTIME) actually
have the same time characteristics wrt. wall-clock time then changing
both as suggested may indeed work. Note however that we are still not
yet in a position to use clock_gettime unconditionally at runtime - its
use is predicated on os::supports_monotonic_clock() (which despite the
name also indicates clock_gettime exists).

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

More next week.

Cheers,
David

On 11/04/2020 3:03 am, Mark Kralj-Taylor wrote:
> I'd like to help Java Clock.systemUTC() expose nanosecond precision
> UTC realtime (wall-time) clock, where OS and CPU allow.
>
> Please let me know if this would be acceptable for OpenJDK, and what
> next steps I can take to progress this towards submitting a patch.
> - I have some time at the moment. I've signed the OCA, but don't have
> login to the OpenJDK bugtracker, if you want me to submit a proper hg
> patch there.
> - This mail includes the patch as `hg diff` outputs together with JMH
> and test output from it.
>
> The patch here improves the existing API java.time.Instant.now() i.e.
> Clock.systemUTC().instant() on Linux to return Linux
> clock_gettime(CLOCK_REALTIME) which can be nanosecond precision (and
> very low cost, se JMH results) when Linux has a suitable clocksource
> (tsc).
>
> change semantics of the existing Clock.systemUTC().instant() API which
>
> Clock.systemUTC().instant() is backed by Hotspot
> os::javaTimeSystemUTC, which can be updated to call higher precision
> OS real-time clock API when available (and has similar performance),
> rather than the current code that multiplies microseconds from
> gettimeofday() by 1000 to get nanoseconds.
>
> In Linux this means calling the Posix clock_gettime(CLOCK_REALTIME)
> API instead of the older gettimeofday() whose output is limited to
> microsecond precision. On a suitable CPU Linux can back
> clock_gettime(CLOCK_REALTIME) with a nanosecond precision CPU TSC
> clocksource. Whereas the output of gettimeofday() is limited to
> microsecond precision (even when Linux is using a higher precision
> clocksource).
>
> A similar change could be made for other OS that offer a performant
> API to get hi-precision wall-time.
> - OSX: Unfortunately on my Mac I found that
> clock_gettime(CLOCK_REALTIME) is limited to microseconds precision
> (source shows it calling gettimeofday() and multiplying by 1000 - see
> note on recent Linux change to discourage that). An alternate approach
> that did get nanosecond precision wall-time was too slow to be of
> interest (>900ns!): Calling OSX host_get_clock_service CALENDAR_CLOCK
> in JVM init, then clock_get_time(clockPortFromPrev,...).
> - Windows: GetSystemTimePreciseAsFileTime looks promising. See
> https://docs.microsoft.com/en-gb/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
> . Unfortunately I don't have access to a Windows machine to try this
> on, but if you are interested in the Linux patch I could buy windows
> for a laptop we have to see how  fares in JMH.
>
> Details, patch and JMH / test outputs follow below.
> Thanks,
> Mark
>
> -----------------
>
> # RATIONAL: Why does Java need nanosecond precision real-time clock?
>
> Like many others working on lower-latency Java systems running on
> Linux I have been using JNI to call clock_gettime(CLOCK_REALTIME, ...)
> to do this for years. Hi-precision (nanosecond) UTC timestamps have
> been essential in understanding and improving end-to-end latency and
> performance of multi-process systems. Including nanosecond wall-time
> after-receive and before-send timestamps in messages sent over the
> wire (or shared memory, or in stored events) gives tremendous
> transparency on latency in multi-process and multi-host event
> processing and workflows.
>
> Java has evolved to remove more and more common cases for JNI. Getting
> a nanosecond real-time clock timestamp feels a good candidate for that
> process, especially because it looks like hi-precision real-time UTC
> clock APIs are common in the minimum OS versions Java is built for
> (even if some OS still give microsecond precision wall-time behind an
> API that returns nanoseconds - as OSX 10.15 did for me - built with
> XCode 10.1 as per JDK docs.
>
> Timestamps from a monotonic clock can only be compared within the same
> host, or for Java's System.nanoTime() within the same Java process.
> This is very useful, but doesn't help with multi-process, multi-host,
> multi-language use-cases.
>
> Realtime (wall-time) UTC clock timestamps are useful because they can
> be compared between different processes, possibly running on a
> different host, as well as within a process. Within the same
> data-centre latency between processes is typically well under a
> millisecond for UDP / multicast between hosts. Latency can be
> sub-microsecond for shared-memory between processes on the same host.
>
> A monotonic clock is often favoured for timing latency, because
> real-time clocks on different hosts are subject to slewing and
> stepping. Clock-sync technologies drastically reduce impact of these
> on a host and also time offsets between different hosts (especially in
> the same data centre). For high event rate systems you can look at
> latency as percentiles over time-windows. With many time-windows you
> get an idea of clock sync quality because you see the distribution
> move when you look at a time-series of percentiles for time-windows if
> different hosts have different clock stepping time synchronisation.
>
> -----------------
>
> # IS THIS A SAFE CHANGE for the JDK?
>
> It makes no change to semantics of Clock.systemUTC(), whose JavaDoc
> says: "This clock is based on the best available system clock. This
> may use System.currentTimeMillis(), or a higher resolution clock if
> one is available.".
>
> Because there is no new JDK API, nor change in API semantics. This
> enhancement can be made on an OS by OS basis.
>
> -----------------
>
> # IS THIS A SAFE CHANGE for Linux?
>
> The "clock_gettime(3) - Linux man page" says: "All implementations
> support the system-wide realtime clock, which is identified by
> CLOCK_REALTIME. Its time represents seconds and nanoseconds since the
> Epoch.". See: https://linux.die.net/man/3/clock_gettime
>
> FYI Some older Linux ports used to implement
> clock_gettime(CLOCK_REALTIME,) by calling gettimeofday() and
> multiplying by 1000. This would be fine with the patch proposed, but
> means that resolution would be limited to microseconds by the OS. A
> Linux change 6 months ago has discouraged that in ports: "Use
> clock_gettime to implement gettimeofday"
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
> .
>
> -----------------
>
> # Related OpenJDK BugTrackers
>
> Comments on these enhancements requests suggest some interest in
> calling Linux clock_gettime(REALTIME) intsead of gettimeofday().
> Although the enhancement requests themselves are not the same as this
> mail, which asks to enhance an existing API, within its existing
> semantics.
> - JDK-6709908
> - JDK-8185891
>
> Since Java 9 Clock.systemUTC() has up to microsecond resolution on Linux
> - JDK-8068730 Increase the precision of the implementation of
> java.time.Clock.systemUTC()
>
> -----------------
>
> # POSSIBLE FOLLOW ON (that is NOT part of the patch or proposal discussed here)
>
> A possible follow-on would be to add a JDK API to give more direct
> (lower cost) access to a hi-precision timestamp as a nanoseconds since
> UTC epoc in a long. For example System.curretTimeNanos(). This would
> be different to the proposal above in that its range would be limited
> to year 2262 for a unsigned long, which is more than 200 years in the
> future, but less than Instant.MAX. A JMH benchmarks with
> systemTimeNanos() as an intrinsic (following the style of
> currentTimeMillis) demonstrated that this is attractive, with similar
> cost to System.currentTimeMillis()/nanoTime(), so better than
> Instant.now() or JNI that I used. But initially I'd rather focus on
> improving Java without adding any new APIs, or discussing if ~200
> years is enough of a range.
>
> -----------------
>
> # PATCHES to Hotspot, tests and output of those tests
>
> ## PATCH to hotspot/os/linux/os_linux.cpp
>
> This patch changes both os::javaTimeMillis and os::javaTimeSystemUTC
> to call clock_gettime(CLOCK_REALTIME, ..) instead of gettimeofday().
> This keeps the 2 methods obviously consistent, and avoids someone
> reading the code having questions on the consistency of different
> Linux APIs. Results form JMH benchmark (see below) show this is ok.
>
> This seams consistent with direction being taken by Linux, based on
> change: "Use clock_gettime to implement gettimeofday" at
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
>
> ```
> diff --git a/src/hotspot/os/linux/os_linux.cpp
> b/src/hotspot/os/linux/os_linux.cpp
> --- a/src/hotspot/os/linux/os_linux.cpp
> +++ b/src/hotspot/os/linux/os_linux.cpp
> @@ -88,6 +88,7 @@
> # include
> # include
> # include
> +# include
> # include
> # include
> # include
> @@ -1374,18 +1375,18 @@
> }
> jlong os::javaTimeMillis() {
> - timeval time;
> - int status = gettimeofday(&time, NULL);
> + timespec time;
> + int status = clock_gettime(CLOCK_REALTIME, &time);
> assert(status != -1, "linux error");
> - return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
> + return jlong(time.tv_sec) * 1000 + jlong(time.tv_nsec / 1000000);
> }
> void os::javaTimeSystemUTC(jlong &seconds, jlong &nanos) {
> - timeval time;
> - int status = gettimeofday(&time, NULL);
> + timespec time;
> + int status = clock_gettime(CLOCK_REALTIME, &time);
> assert(status != -1, "linux error");
> seconds = jlong(time.tv_sec);
> - nanos = jlong(time.tv_usec) * 1000;
> + nanos = jlong(time.tv_nsec);
> }
> ```
>
> ## PATCH to test/micro JMH benchmark to assess impact of change on
> Instant.now(), and show its performance relative to
> System.currentTimeMillis()/nanoTime().
>
> Where would the best place be to add an Instant.now() JMH bennchmark?
> - While I'd guess the convention is to follow the package of the API
> being benchmarked. I like that by putting benchmarks of system
> timestamping APIs in one class its easy and natural to spot them all
> and compare them. Could the benchmark be added here, then the class
> renamed to SystemTime.java to focus on benchmarking those features?
>
> ```
> diff --git a/test/micro/org/openjdk/bench/java/lang/Systems.java
> b/test/micro/org/openjdk/bench/java/lang/Systems.java
> --- a/test/micro/org/openjdk/bench/java/lang/Systems.java
> +++ b/test/micro/org/openjdk/bench/java/lang/Systems.java
> @@ -28,6 +28,7 @@
> import org.openjdk.jmh.annotations.OutputTimeUnit;
> import java.util.concurrent.TimeUnit;
> +import java.time.Instant;
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @@ -43,4 +44,9 @@
> return System.nanoTime();
> }
> + @Benchmark
> + public long instant_now_asEpocNanos() {
> + Instant now = Instant.now();
> + return now.getEpochSecond() * 1_000_000_000L + now.getNano();
> + }
> ```
>
> ### RESULTS from JDK Micro benchmark:
> Run on Linux with clocksource=tsc on a 3GHz Intel i5 CPU (see details below).
>
> `make test TEST="micro:java.lang.Systems"`
>
> WITH change to os_linux.cpp:
> ```
> Benchmark Mode Cnt Score Error Units
> Systems.currentTimeMillis avgt 25 19.190 ? 0.166 ns/op
> Systems.instant_now_asEpocNanos avgt 25 29.809 ? 0.191 ns/op
> Systems.nanoTime avgt 25 18.534 ? 0.024 ns/op
> ```
>
> WITHOUT change to os_linux.cpp: (but with the added JMH benchmark for
> purpose of comparison)
> ```
> Benchmark Mode Cnt Score Error Units
> Systems.currentTimeMillis avgt 25 19.013 ? 0.033 ns/op
> Systems.instant_now_asEpocNanos avgt 25 30.459 ? 0.017 ns/op
> Systems.nanoTime avgt 25 18.971 ? 0.053 ns/op
> ```
>
> ### Platform details:
> System: Linux (Ubuntu) running on Mac Mini 2018 3 GHz Intel i5
> ```
> \$ uname -a
> Linux MacMiniLinux 5.3.0-42-generic #34-Ubuntu SMP Fri Feb 28 05:49:40
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> \$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
> \$ ldd --version
> ldd (Ubuntu GLIBC 2.30-0ubuntu2.1) 2.30
>
> \$ lscpu | egrep '(Model name|CPU.s.:)'
> CPU(s): 6
> Model name: Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
> NUMA node0 CPU(s): 0-5
>
> \$ lscpu | grep Flags | sed 's@ @\n at g' | grep -i tsc
> tsc
> rdtscp
> constant_tsc
> nonstop_tsc
> ```
>
> ## PATCH to JDK test code - that logs realtime clock precision:
>
> ```
> diff --git a/test/jdk/java/time/test/java/time/TestClock_System.java
> b/test/jdk/java/time/test/java/time/TestClock_System.java
> --- a/test/jdk/java/time/test/java/time/TestClock_System.java
> +++ b/test/jdk/java/time/test/java/time/TestClock_System.java
> @@ -177,7 +177,8 @@
> + formatTime("\n\thighest1", highest1));
> }
> - int count=0;
> + int count_betterThanMillisPrecision=0;
> + int count_betterThanMicrosPrecision=0;
> // let's preheat the system a bit:
> int lastNanos = 0;
> for (int i = 0; i < 1000 ; i++) {
> @@ -191,7 +192,10 @@
> lastNanos = nanos;
> if ((nanos % 1000000) > 0) {
> - count++; // we have micro seconds
> + count_betterThanMillisPrecision++; // we have microseconds
> + }
> + if ((nanos % 1000) > 0) {
> + count_betterThanMicrosPrecision++; // we have nanoseconds
> }
> if ((sysnan % 1000000) > 0) {
> throw new RuntimeException("Expected only millisecconds "
> @@ -200,10 +204,12 @@
> }
> }
> System.out.println("\nNumber of time stamps which had better than"
> - + " millisecond precision: "+count+"/"+1000);
> + + " millisecond precision: "+count_betterThanMillisPrecision+"/"+1000);
> + System.out.println("\nNumber of time stamps which had better than"
> + + " microsecond precision: "+count_betterThanMicrosPrecision+"/"+1000);
> System.out.println(formatTime("\nsystemUTC ", system1));
> System.out.println(formatTime("highestResolutionUTC ", highest1));
> - if (count == 0) {
> + if (count_betterThanMillisPrecision == 0) {
> System.err.println("Something is strange: no microsecond "
> + "precision with highestResolutionUTC?");
> throw new RuntimeException("Micro second preccision not reached");
> ```
>
> ### OUTPUT of JDK Test logs observed clock precision
>
> Extract of test log when test patch run on same host as JMH below.
> Shows nanosecond precision (`999/1000 better than microsecond`).
>
> `make test TEST="jtreg:test/jdk/java/time/test/java/time/TestClock_System.java"
> JTREG="VERBOSE=all"`
>
> ```
> Number of time stamps which had better than millisecond precision: 1000/1000
>
> Number of time stamps which had better than microsecond precision: 999/1000
>
> systemUTC : 2020-04-03T23:14:12.276Z - seconds: 1585955652, nanos: 276000000
> highestResolutionUTC : 2020-04-03T23:14:12.276472680Z - seconds:
> 1585955652, nanos: 276472680
> ```
>

From david.holmes at oracle.com  Fri Apr 10 23:53:48 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Apr 2020 09:53:48 +1000
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
Message-ID: <9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

Update:

On 11/04/2020 9:45 am, David Holmes wrote:
> Hi Mark,
>
> Thanks for the very detailed proposal and write up!
>
> It's a holiday weekend so I can't dig into this right now but we tried
> using a high-precision clock source for systemUTC() in the past but it
> didn't work because systemUTC() and currentTimeMillis() have to use the
> same time base, and currentTimeMillis() has to use gettimeofday(). I
> thought this cross-dependency was documented somewhere but can't find it
> right now. If gettimeofday and clock_gettime(CLOCK_REALTIME) actually
> have the same time characteristics wrt. wall-clock time then changing
> both as suggested may indeed work.

Found this from last time things were discussed in detail:

https://bugs.openjdk.java.net/browse/JDK-8185891?focusedCommentId=14107380&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14107380

so it does seem like a switch from gettimeofday to
clock_gettime(CLOCK_REALTIME) may be viable.

Cheers,
David

> Note however that we are still not
> yet in a position to use clock_gettime unconditionally at runtime - its
> use is predicated on os::supports_monotonic_clock() (which despite the
> name also indicates clock_gettime exists).
>
>
> https://bugs.openjdk.java.net/browse/JDK-8180466
>
> More next week.
>
> Cheers,
> David
>
> On 11/04/2020 3:03 am, Mark Kralj-Taylor wrote:
>> I'd like to help Java Clock.systemUTC() expose nanosecond precision
>> UTC realtime (wall-time) clock, where OS and CPU allow.
>>
>> Please let me know if this would be acceptable for OpenJDK, and what
>> next steps I can take to progress this towards submitting a patch.
>> - I have some time at the moment. I've signed the OCA, but don't have
>> login to the OpenJDK bugtracker, if you want me to submit a proper hg
>> patch there.
>> - This mail includes the patch as `hg diff` outputs together with JMH
>> and test output from it.
>>
>> The patch here improves the existing API java.time.Instant.now() i.e.
>> Clock.systemUTC().instant() on Linux to return Linux
>> clock_gettime(CLOCK_REALTIME) which can be nanosecond precision (and
>> very low cost, se JMH results) when Linux has a suitable clocksource
>> (tsc).
>>
>> change semantics of the existing Clock.systemUTC().instant() API which
>>
>> Clock.systemUTC().instant() is backed by Hotspot
>> os::javaTimeSystemUTC, which can be updated to call higher precision
>> OS real-time clock API when available (and has similar performance),
>> rather than the current code that multiplies microseconds from
>> gettimeofday() by 1000 to get nanoseconds.
>>
>> In Linux this means calling the Posix clock_gettime(CLOCK_REALTIME)
>> API instead of the older gettimeofday() whose output is limited to
>> microsecond precision. On a suitable CPU Linux can back
>> clock_gettime(CLOCK_REALTIME) with a nanosecond precision CPU TSC
>> clocksource. Whereas the output of gettimeofday() is limited to
>> microsecond precision (even when Linux is using a higher precision
>> clocksource).
>>
>> A similar change could be made for other OS that offer a performant
>> API to get hi-precision wall-time.
>> - OSX: Unfortunately on my Mac I found that
>> clock_gettime(CLOCK_REALTIME) is limited to microseconds precision
>> (source shows it calling gettimeofday() and multiplying by 1000 - see
>> note on recent Linux change to discourage that). An alternate approach
>> that did get nanosecond precision wall-time was too slow to be of
>> interest (>900ns!): Calling OSX host_get_clock_service CALENDAR_CLOCK
>> in JVM init, then clock_get_time(clockPortFromPrev,...).
>> - Windows: GetSystemTimePreciseAsFileTime looks promising. See
>> https://docs.microsoft.com/en-gb/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
>>
>> . Unfortunately I don't have access to a Windows machine to try this
>> on, but if you are interested in the Linux patch I could buy windows
>> for a laptop we have to see how? fares in JMH.
>>
>> Details, patch and JMH / test outputs follow below.
>> Thanks,
>> Mark
>>
>> -----------------
>>
>> # RATIONAL: Why does Java need nanosecond precision real-time clock?
>>
>> Like many others working on lower-latency Java systems running on
>> Linux I have been using JNI to call clock_gettime(CLOCK_REALTIME, ...)
>> to do this for years. Hi-precision (nanosecond) UTC timestamps have
>> been essential in understanding and improving end-to-end latency and
>> performance of multi-process systems. Including nanosecond wall-time
>> after-receive and before-send timestamps in messages sent over the
>> wire (or shared memory, or in stored events) gives tremendous
>> transparency on latency in multi-process and multi-host event
>> processing and workflows.
>>
>> Java has evolved to remove more and more common cases for JNI. Getting
>> a nanosecond real-time clock timestamp feels a good candidate for that
>> process, especially because it looks like hi-precision real-time UTC
>> clock APIs are common in the minimum OS versions Java is built for
>> (even if some OS still give microsecond precision wall-time behind an
>> API that returns nanoseconds - as OSX 10.15 did for me - built with
>> XCode 10.1 as per JDK docs.
>>
>> Timestamps from a monotonic clock can only be compared within the same
>> host, or for Java's System.nanoTime() within the same Java process.
>> This is very useful, but doesn't help with multi-process, multi-host,
>> multi-language use-cases.
>>
>> Realtime (wall-time) UTC clock timestamps are useful because they can
>> be compared between different processes, possibly running on a
>> different host, as well as within a process. Within the same
>> data-centre latency between processes is typically well under a
>> millisecond for UDP / multicast between hosts. Latency can be
>> sub-microsecond for shared-memory between processes on the same host.
>>
>> A monotonic clock is often favoured for timing latency, because
>> real-time clocks on different hosts are subject to slewing and
>> stepping. Clock-sync technologies drastically reduce impact of these
>> on a host and also time offsets between different hosts (especially in
>> the same data centre). For high event rate systems you can look at
>> latency as percentiles over time-windows. With many time-windows you
>> get an idea of clock sync quality because you see the distribution
>> move when you look at a time-series of percentiles for time-windows if
>> different hosts have different clock stepping time synchronisation.
>>
>> -----------------
>>
>> # IS THIS A SAFE CHANGE for the JDK?
>>
>> It makes no change to semantics of Clock.systemUTC(), whose JavaDoc
>> says: "This clock is based on the best available system clock. This
>> may use System.currentTimeMillis(), or a higher resolution clock if
>> one is available.".
>>
>> Because there is no new JDK API, nor change in API semantics. This
>> enhancement can be made on an OS by OS basis.
>>
>> -----------------
>>
>> # IS THIS A SAFE CHANGE for Linux?
>>
>> The "clock_gettime(3) - Linux man page" says: "All implementations
>> support the system-wide realtime clock, which is identified by
>> CLOCK_REALTIME. Its time represents seconds and nanoseconds since the
>> Epoch.". See: https://linux.die.net/man/3/clock_gettime
>>
>> FYI Some older Linux ports used to implement
>> clock_gettime(CLOCK_REALTIME,) by calling gettimeofday() and
>> multiplying by 1000. This would be fine with the patch proposed, but
>> means that resolution would be limited to microseconds by the OS. A
>> Linux change 6 months ago has discouraged that in ports: "Use
>> clock_gettime to implement gettimeofday"
>> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
>>
>> .
>>
>> -----------------
>>
>> # Related OpenJDK BugTrackers
>>
>> Comments on these enhancements requests suggest some interest in
>> calling Linux clock_gettime(REALTIME) intsead of gettimeofday().
>> Although the enhancement requests themselves are not the same as this
>> mail, which asks to enhance an existing API, within its existing
>> semantics.
>> - JDK-6709908
>> - JDK-8185891
>>
>> Since Java 9 Clock.systemUTC() has up to microsecond resolution on Linux
>> - JDK-8068730 Increase the precision of the implementation of
>> java.time.Clock.systemUTC()
>>
>> -----------------
>>
>> # POSSIBLE FOLLOW ON (that is NOT part of the patch or proposal
>> discussed here)
>>
>> A possible follow-on would be to add a JDK API to give more direct
>> (lower cost) access to a hi-precision timestamp as a nanoseconds since
>> UTC epoc in a long. For example System.curretTimeNanos(). This would
>> be different to the proposal above in that its range would be limited
>> to year 2262 for a unsigned long, which is more than 200 years in the
>> future, but less than Instant.MAX. A JMH benchmarks with
>> systemTimeNanos() as an intrinsic (following the style of
>> currentTimeMillis) demonstrated that this is attractive, with similar
>> cost to System.currentTimeMillis()/nanoTime(), so better than
>> Instant.now() or JNI that I used. But initially I'd rather focus on
>> improving Java without adding any new APIs, or discussing if ~200
>> years is enough of a range.
>>
>> -----------------
>>
>> # PATCHES to Hotspot, tests and output of those tests
>>
>> ## PATCH to hotspot/os/linux/os_linux.cpp
>>
>> This patch changes both os::javaTimeMillis and os::javaTimeSystemUTC
>> to call clock_gettime(CLOCK_REALTIME, ..) instead of gettimeofday().
>> This keeps the 2 methods obviously consistent, and avoids someone
>> reading the code having questions on the consistency of different
>> Linux APIs. Results form JMH benchmark (see below) show this is ok.
>>
>> This seams consistent with direction being taken by Linux, based on
>> change: "Use clock_gettime to implement gettimeofday" at
>> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b
>>
>>
>> ```
>> diff --git a/src/hotspot/os/linux/os_linux.cpp
>> b/src/hotspot/os/linux/os_linux.cpp
>> --- a/src/hotspot/os/linux/os_linux.cpp
>> +++ b/src/hotspot/os/linux/os_linux.cpp
>> @@ -88,6 +88,7 @@
>> # include
>> # include
>> # include
>> +# include
>> # include
>> # include
>> # include
>> @@ -1374,18 +1375,18 @@
>> }
>> jlong os::javaTimeMillis() {
>> - timeval time;
>> - int status = gettimeofday(&time, NULL);
>> + timespec time;
>> + int status = clock_gettime(CLOCK_REALTIME, &time);
>> assert(status != -1, "linux error");
>> - return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
>> + return jlong(time.tv_sec) * 1000 + jlong(time.tv_nsec / 1000000);
>> }
>> void os::javaTimeSystemUTC(jlong &seconds, jlong &nanos) {
>> - timeval time;
>> - int status = gettimeofday(&time, NULL);
>> + timespec time;
>> + int status = clock_gettime(CLOCK_REALTIME, &time);
>> assert(status != -1, "linux error");
>> seconds = jlong(time.tv_sec);
>> - nanos = jlong(time.tv_usec) * 1000;
>> + nanos = jlong(time.tv_nsec);
>> }
>> ```
>>
>> ## PATCH to test/micro JMH benchmark to assess impact of change on
>> Instant.now(), and show its performance relative to
>> System.currentTimeMillis()/nanoTime().
>>
>> Where would the best place be to add an Instant.now() JMH bennchmark?
>> - While I'd guess the convention is to follow the package of the API
>> being benchmarked. I like that by putting benchmarks of system
>> timestamping APIs in one class its easy and natural to spot them all
>> and compare them. Could the benchmark be added here, then the class
>> renamed to SystemTime.java to focus on benchmarking those features?
>>
>> ```
>> diff --git a/test/micro/org/openjdk/bench/java/lang/Systems.java
>> b/test/micro/org/openjdk/bench/java/lang/Systems.java
>> --- a/test/micro/org/openjdk/bench/java/lang/Systems.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/Systems.java
>> @@ -28,6 +28,7 @@
>> import org.openjdk.jmh.annotations.OutputTimeUnit;
>> import java.util.concurrent.TimeUnit;
>> +import java.time.Instant;
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @@ -43,4 +44,9 @@
>> return System.nanoTime();
>> }
>> + @Benchmark
>> + public long instant_now_asEpocNanos() {
>> + Instant now = Instant.now();
>> + return now.getEpochSecond() * 1_000_000_000L + now.getNano();
>> + }
>> ```
>>
>> ### RESULTS from JDK Micro benchmark:
>> Run on Linux with clocksource=tsc on a 3GHz Intel i5 CPU (see details
>> below).
>>
>> `make test TEST="micro:java.lang.Systems"`
>>
>> WITH change to os_linux.cpp:
>> ```
>> Benchmark Mode Cnt Score Error Units
>> Systems.currentTimeMillis avgt 25 19.190 ? 0.166 ns/op
>> Systems.instant_now_asEpocNanos avgt 25 29.809 ? 0.191 ns/op
>> Systems.nanoTime avgt 25 18.534 ? 0.024 ns/op
>> ```
>>
>> WITHOUT change to os_linux.cpp: (but with the added JMH benchmark for
>> purpose of comparison)
>> ```
>> Benchmark Mode Cnt Score Error Units
>> Systems.currentTimeMillis avgt 25 19.013 ? 0.033 ns/op
>> Systems.instant_now_asEpocNanos avgt 25 30.459 ? 0.017 ns/op
>> Systems.nanoTime avgt 25 18.971 ? 0.053 ns/op
>> ```
>>
>> ### Platform details:
>> System: Linux (Ubuntu) running on Mac Mini 2018 3 GHz Intel i5
>> ```
>> \$ uname -a
>> Linux MacMiniLinux 5.3.0-42-generic #34-Ubuntu SMP Fri Feb 28 05:49:40
>> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>>
>> \$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>>
>> \$ ldd --version
>> ldd (Ubuntu GLIBC 2.30-0ubuntu2.1) 2.30
>>
>> \$ lscpu | egrep '(Model name|CPU.s.:)'
>> CPU(s): 6
>> Model name: Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
>> NUMA node0 CPU(s): 0-5
>>
>> \$ lscpu | grep Flags | sed 's@ @\n at g' | grep -i tsc
>> tsc
>> rdtscp
>> constant_tsc
>> nonstop_tsc
>> ```
>>
>> ## PATCH to JDK test code - that logs realtime clock precision:
>>
>> ```
>> diff --git a/test/jdk/java/time/test/java/time/TestClock_System.java
>> b/test/jdk/java/time/test/java/time/TestClock_System.java
>> --- a/test/jdk/java/time/test/java/time/TestClock_System.java
>> +++ b/test/jdk/java/time/test/java/time/TestClock_System.java
>> @@ -177,7 +177,8 @@
>> + formatTime("\n\thighest1", highest1));
>> }
>> - int count=0;
>> + int count_betterThanMillisPrecision=0;
>> + int count_betterThanMicrosPrecision=0;
>> // let's preheat the system a bit:
>> int lastNanos = 0;
>> for (int i = 0; i < 1000 ; i++) {
>> @@ -191,7 +192,10 @@
>> lastNanos = nanos;
>> if ((nanos % 1000000) > 0) {
>> - count++; // we have micro seconds
>> + count_betterThanMillisPrecision++; // we have microseconds
>> + }
>> + if ((nanos % 1000) > 0) {
>> + count_betterThanMicrosPrecision++; // we have nanoseconds
>> }
>> if ((sysnan % 1000000) > 0) {
>> throw new RuntimeException("Expected only millisecconds "
>> @@ -200,10 +204,12 @@
>> }
>> }
>> System.out.println("\nNumber of time stamps which had better than"
>> - + " millisecond precision: "+count+"/"+1000);
>> + + " millisecond precision: "+count_betterThanMillisPrecision+"/"+1000);
>> + System.out.println("\nNumber of time stamps which had better than"
>> + + " microsecond precision: "+count_betterThanMicrosPrecision+"/"+1000);
>> System.out.println(formatTime("\nsystemUTC ", system1));
>> System.out.println(formatTime("highestResolutionUTC ", highest1));
>> - if (count == 0) {
>> + if (count_betterThanMillisPrecision == 0) {
>> System.err.println("Something is strange: no microsecond "
>> + "precision with highestResolutionUTC?");
>> throw new RuntimeException("Micro second preccision not reached");
>> ```
>>
>> ### OUTPUT of JDK Test logs observed clock precision
>>
>> Extract of test log when test patch run on same host as JMH below.
>> Shows nanosecond precision (`999/1000 better than microsecond`).
>>
>> `make test
>> TEST="jtreg:test/jdk/java/time/test/java/time/TestClock_System.java"
>> JTREG="VERBOSE=all"`
>>
>> ```
>> Number of time stamps which had better than millisecond precision:
>> 1000/1000
>>
>> Number of time stamps which had better than microsecond precision:
>> 999/1000
>>
>> systemUTC : 2020-04-03T23:14:12.276Z - seconds: 1585955652, nanos:
>> 276000000
>> highestResolutionUTC : 2020-04-03T23:14:12.276472680Z - seconds:
>> 1585955652, nanos: 276472680
>> ```
>>

From suenaga at oss.nttdata.com  Sat Apr 11 01:18:06 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Sat, 11 Apr 2020 10:18:06 +0900
Subject: RFR: 8242283: Can't start JVM when java home path includes
non-ASCII character
References: <94ea9f9f-75a9-f9a4-da74-8c583d62b1f2@oss.nttdata.com>

Thanks Sato-san!

Can I get reviewer(s) from HotSpot folks?
This webrev changes HotSpot code (os_windows.cpp).

Yasumasa

On 2020/04/11 2:17, naoto.sato at oracle.com wrote:
> Suenaga-san,
>
> Looks good to me. Please add noreg-hard if you are not planning to provide test cases. Thank you for fixing this issue.
>
> Naoto
>
> On 4/10/20 7:29 AM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>>
>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8242283
>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242283/webrev.00/
>>
>> After JDK-8240197 and JDK-8240725, java cannot start when java home path includes non-ASCII character e.g. Japanese Kanji.
>>
>> But this change would not resolve in all cases. For example, Japanese encoded pathname cannot be recognized under the English system locale. It is (implicitly) described in the spec for JNI_CreateJavaVM().
>>
>> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/invocation.html#jni_createjavavm:
>> ```
>> ???? char *optionString; /* the option as a string in the default platform encoding */
>> ```
>>
>>
>> Thanks,
>>
>> Yasumasa

From eirbjo at gmail.com  Fri Apr 10 18:46:14 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 10 Apr 2020 20:46:14 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
Message-ID:

I recently needed to re-implement multi-release lookup logic for a
[1]

It occurred to me that JarFile.getVersionedEntry checks _every_ version
between 8 and the runtime version when looking up paths.

Since META-INF/versions will probably be sparsely populated, I'm wondering
if something could be done to avoid checking 20 different paths in OpenJDK
28.

Perhaps scanning META-INF/versions once when opening the file could work,
then only check existing versions in getVersionedEntry?

Maybe a premature optimization today, but with the new release cadence,
this problem is going to surface at some point in the future, right?

[1]
https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html

Eirik.

From eirbjo at gmail.com  Sat Apr 11 19:10:14 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 11 Apr 2020 21:10:14 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>
Message-ID:

Lance,

I made a small performance test. Pretty sloppy, so please don't tell
Aleksey S :-)

Results indicate there may be some performance wins to be had.

The test uses the Maven artifact com.h2database:h2:1.4.200:jar. This jar
which has 950 entries, of which the following three are versioned:

META-INF/versions/10/org/h2/util/NetUtils2.class
META-INF/versions/9/org/h2/util/Bits.class
META-INF/versions/9/org/h2/util/CurrentTimestamp.class

The performance test calls JarFile.getEntry for each of the base names
found in the jar. It does so 2000 times for 50 iterations and calculates
the average run time.

This is done once on a JarFile opened with runtime version 15, once on a
JarFile opened with runtime version 8 (which effectively disables versioned
lookup so works as a baseline). Warmup runs are run first to get stable
results.

The test is run with OpenJDK 15 built from master.

Results:

Average time to get 950 entries 2000 times:

Runtime version 15: 2903 ms
Runtime version 8: 336 ms:

This is shows the difference between testing seven versions (9, 10, 11, 12,
13, 14, 15) and not testing versions.

I then made a change to JarFile which scans the versions up front and
stores them in an int[] which is then looped over in getVersionedEntry.

Results:

Runtime version 15: 1048 ms
Runtime version 8: 315 ms:

My benchmark is of course synthetic and does not represent reality. I have
not done any analysis on the shape of typical multi-versioned jars nor
their access patterns.

However, an improvement of 2.5 - 3x is maybe worth taking a closer look?

Here's the patch for my change in JarFile.java:

Index: src/java.base/share/classes/java/util/jar/JarFile.java
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/java.base/share/classes/java/util/jar/JarFile.java (revision
86722cb038d3030c51f3268799a2c3dc0c508638)
+++ src/java.base/share/classes/java/util/jar/JarFile.java (date
1586631626679)
@@ -161,7 +161,7 @@
private final Runtime.Version version;  // current version
private final int versionFeature;       // version.feature()
private boolean isMultiRelease;         // is jar multi-release?
-
+    private int[] versions;                 // which versions does the jar
contain
// indicates if Class-Path attribute present
private boolean hasClassPathAttribute;
// true if manifest checked for special attributes
@@ -599,12 +599,13 @@
}

private JarEntry getVersionedEntry(String name, JarEntry je) {
-        if (BASE_VERSION_FEATURE < versionFeature) {
+        int[] versions = this.versions;
+        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
versions.length > 0) {
if (!name.startsWith(META_INF)) {
// search for versioned entry
-                int v = versionFeature;
-                while (v > BASE_VERSION_FEATURE) {
-                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
"/" + name);
+                int v = versions.length - 1;
+                while (v >= 0) {
+                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
versions[v] + "/" + name);
if (vje != null) {
return vje.withBasename(name);
}
@@ -1016,9 +1017,20 @@
byte[] lbuf = new byte[512];
Attributes attr = new Attributes();
-                            new ByteArrayInputStream(b)), lbuf);
-                        isMultiRelease = Boolean.parseBoolean(
-                            attr.getValue(Attributes.Name.MULTI_RELEASE));
+                                new ByteArrayInputStream(b)), lbuf);
+                        if(Boolean.parseBoolean(
+
attr.getValue(Attributes.Name.MULTI_RELEASE))) {
+                            isMultiRelease = true;
+                            versions = this.stream()
+                                    .map(ZipEntry::getName)
+                                    .mapToInt(this::parseVersion)
+                                    .filter(v -> v != -1 && v >=
BASE_VERSION_FEATURE && v <= versionFeature)
+                                    .distinct()
+                                    .sorted()
+                                    .toArray();
+
+                        }
+
}
}
}
@@ -1026,6 +1038,27 @@
}
}

+    /**
+     * If {@code entryName} is a a versioned entry, parse and return the
version as an integer, otherwise return -1
+     */
+    private int parseVersion(String entryName) {
+        if(!entryName.startsWith(META_INF_VERSIONS)) {
+            return -1;
+        }
+
+        int separator = entryName.indexOf("/", META_INF_VERSIONS.length());
+
+        if(separator == -1) {
+            return -1;
+        }
+
+        try {
+            return Integer.parseInt(entryName, META_INF_VERSIONS.length(),
separator, 10);
+        } catch (NumberFormatException e) {
+            return -1;
+        }
+    }
+
synchronized void ensureInitialization() {
try {
maybeInstantiateVerifier();

On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen
wrote:

> Hi Eric
>
> Feel free to enter a feature request and better yet propose a fix :-)
>
> Have a good weekend!
>
> Best
> Lance
>
> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
>
> I recently needed to re-implement multi-release lookup logic for a
> [1]
>
> It occurred to me that JarFile.getVersionedEntry checks _every_ version
> between 8 and the runtime version when looking up paths.
>
> Since META-INF/versions will probably be sparsely populated, I'm wondering
> if something could be done to avoid checking 20 different paths in OpenJDK
> 28.
>
> Perhaps scanning META-INF/versions once when opening the file could work,
> then only check existing versions in getVersionedEntry?
>
> Maybe a premature optimization today, but with the new release cadence,
> this problem is going to surface at some point in the future, right?
>
> [1]
> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>
> Eirik.
>
>
>
>
>
> 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 vipinsharma85 at gmail.com  Sat Apr 11 19:23:57 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Sun, 12 Apr 2020 00:53:57 +0530
References:

<98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>

<912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
<9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>

Message-ID: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>

Hi Pavel,

> On Apr 9, 2020, at 2:45 AM, Pavel Rappo  wrote:
>
> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>

--- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
+++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
@@ -142,7 +142,7 @@
/**
* Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
* data the index array offset of the indexes for that lead surrogate.
-        * @param property data value for a surrogate from the trie, including
+        * @param value data value for a surrogate from the trie, including
*        the folding offset
* @return data offset or 0 if there is no data for the lead surrogate
*/
--- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
+++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
@@ -1,5 +1,5 @@
/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -39,7 +39,7 @@

/**
* Calls FilterInputStream's constructor.
-     * @param an InputStream
+     * @param is an InputStream
*/
PlainTextInputStream(InputStream is) {
super(is);
--- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
@@ -1,5 +1,5 @@
/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -881,7 +881,7 @@
* only CRLs signed with a different key (but the same issuer
* name) as the certificate being checked.
*
-     * @param currCert the `X509Certificate` to be checked
+     * @param cert the `X509Certificate` to be checked
* @param prevKey the `PublicKey` that failed
* @param signFlag `true` if that key was trusted to sign CRLs
* @param stackedCerts a `Set` of `X509Certificate`s>
--- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
@@ -1,5 +1,5 @@
/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -166,7 +166,7 @@
/**
* Creates a URICertStore.
*
-     * @param parameters specifying the URI
+     * @param params parameters specifying the URI
*/
URICertStore(CertStoreParameters params)
throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
--- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
+++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
@@ -1,5 +1,5 @@
/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -483,7 +483,7 @@
* and its corresponding CertId.
*
* @param subjectCert the certificate to be checked for revocation
-         * @param cid the CertId for {@code subjectCert}
+         * @param certId the CertId for {@code subjectCert}
*/
StatusInfo(X509Certificate subjectCert, CertId certId) {
cert = subjectCert;
--- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
+++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
@@ -1,5 +1,5 @@
/*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -193,7 +193,7 @@
/**
* Constructs an object to store the response to a timestamp request.
*
-     * @param status A buffer containing the ASN.1 BER encoded response.
+     * @param tsReply A buffer containing the ASN.1 BER encoded response.
* @throws IOException The exception is thrown if a problem is encountered
*         parsing the timestamp response.
*/

>> On 8 Apr 2020, at 17:35, Vipin Sharma  wrote:
>>
>>
>>
>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo  wrote:
>>>
>>> Why assume something that sophisticated where it can be adequately explained by
>>> a simpler thing? :) I bet it was an IDE inspection.
>>>
>>> -Pavel
>>
>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>
>>>
>>>> On 8 Apr 2020, at 14:14, Alan Bateman  wrote:
>>>>
>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>> nor imported
>>>>>
>>>>> Hopefully that's only on internal classes.
>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>
>>>> -Alan
>>>
>>
>> Regards,
>> Vipin
>
Regards,
Vipin

From eirbjo at gmail.com  Sat Apr 11 20:06:49 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 11 Apr 2020 22:06:49 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID:

There's an added up-front cost to scanning versions which I have also tried
to test.

Since checkForSpecialAttributes is lazy, this can be tested by measuring
the time taken to read the first entry of an open JarFile. For the h2 jar
file, this seems to take ~350 microseconds without my patch, which
increases to ~850 microseconds with the patch.

This cost applies to the first getEntry call and is then amortized over all
following calls.

So this patch is probably not a win for use cases where very few entries

Eirik.

On Sat, Apr 11, 2020 at 9:10 PM Eirik Bj?rsn?s  wrote:

>
> Lance,
>
> I made a small performance test. Pretty sloppy, so please don't tell
> Aleksey S :-)
>
> Results indicate there may be some performance wins to be had.
>
> The test uses the Maven artifact com.h2database:h2:1.4.200:jar. This jar
> which has 950 entries, of which the following three are versioned:
>
> META-INF/versions/10/org/h2/util/NetUtils2.class
> META-INF/versions/9/org/h2/util/Bits.class
> META-INF/versions/9/org/h2/util/CurrentTimestamp.class
>
> The performance test calls JarFile.getEntry for each of the base names
> found in the jar. It does so 2000 times for 50 iterations and calculates
> the average run time.
>
> This is done once on a JarFile opened with runtime version 15, once on a
> JarFile opened with runtime version 8 (which effectively disables versioned
> lookup so works as a baseline). Warmup runs are run first to get stable
> results.
>
> The test is run with OpenJDK 15 built from master.
>
> Results:
>
> Average time to get 950 entries 2000 times:
>
> Runtime version 15: 2903 ms
> Runtime version 8: 336 ms:
>
> This is shows the difference between testing seven versions (9, 10, 11,
> 12, 13, 14, 15) and not testing versions.
>
> I then made a change to JarFile which scans the versions up front and
> stores them in an int[] which is then looped over in getVersionedEntry.
>
> Results:
>
> Runtime version 15: 1048 ms
> Runtime version 8: 315 ms:
>
> My benchmark is of course synthetic and does not represent reality. I have
> not done any analysis on the shape of typical multi-versioned jars nor
> their access patterns.
>
> However, an improvement of 2.5 - 3x is maybe worth taking a closer look?
>
> Here's the patch for my change in JarFile.java:
>
> Index: src/java.base/share/classes/java/util/jar/JarFile.java
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- src/java.base/share/classes/java/util/jar/JarFile.java (revision
> 86722cb038d3030c51f3268799a2c3dc0c508638)
> +++ src/java.base/share/classes/java/util/jar/JarFile.java (date
> 1586631626679)
> @@ -161,7 +161,7 @@
>      private final Runtime.Version version;  // current version
>      private final int versionFeature;       // version.feature()
>      private boolean isMultiRelease;         // is jar multi-release?
> -
> +    private int[] versions;                 // which versions does the
> jar contain
>      // indicates if Class-Path attribute present
>      private boolean hasClassPathAttribute;
>      // true if manifest checked for special attributes
> @@ -599,12 +599,13 @@
>      }
>
>      private JarEntry getVersionedEntry(String name, JarEntry je) {
> -        if (BASE_VERSION_FEATURE < versionFeature) {
> +        int[] versions = this.versions;
> +        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
> versions.length > 0) {
>              if (!name.startsWith(META_INF)) {
>                  // search for versioned entry
> -                int v = versionFeature;
> -                while (v > BASE_VERSION_FEATURE) {
> -                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
> "/" + name);
> +                int v = versions.length - 1;
> +                while (v >= 0) {
> +                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
> versions[v] + "/" + name);
>                      if (vje != null) {
>                          return vje.withBasename(name);
>                      }
> @@ -1016,9 +1017,20 @@
>                          byte[] lbuf = new byte[512];
>                          Attributes attr = new Attributes();
> -                            new ByteArrayInputStream(b)), lbuf);
> -                        isMultiRelease = Boolean.parseBoolean(
> -                            attr.getValue(Attributes.Name.MULTI_RELEASE));
> +                                new ByteArrayInputStream(b)), lbuf);
> +                        if(Boolean.parseBoolean(
> +
>  attr.getValue(Attributes.Name.MULTI_RELEASE))) {
> +                            isMultiRelease = true;
> +                            versions = this.stream()
> +                                    .map(ZipEntry::getName)
> +                                    .mapToInt(this::parseVersion)
> +                                    .filter(v -> v != -1 && v >=
> BASE_VERSION_FEATURE && v <= versionFeature)
> +                                    .distinct()
> +                                    .sorted()
> +                                    .toArray();
> +
> +                        }
> +
>                      }
>                  }
>              }
> @@ -1026,6 +1038,27 @@
>          }
>      }
>
> +    /**
> +     * If {@code entryName} is a a versioned entry, parse and return the
> version as an integer, otherwise return -1
> +     */
> +    private int parseVersion(String entryName) {
> +        if(!entryName.startsWith(META_INF_VERSIONS)) {
> +            return -1;
> +        }
> +
> +        int separator = entryName.indexOf("/",
> META_INF_VERSIONS.length());
> +
> +        if(separator == -1) {
> +            return -1;
> +        }
> +
> +        try {
> +            return Integer.parseInt(entryName,
> META_INF_VERSIONS.length(), separator, 10);
> +        } catch (NumberFormatException e) {
> +            return -1;
> +        }
> +    }
> +
>      synchronized void ensureInitialization() {
>          try {
>              maybeInstantiateVerifier();
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen
> wrote:
>
>> Hi Eric
>>
>> Feel free to enter a feature request and better yet propose a fix :-)
>>
>> Have a good weekend!
>>
>> Best
>> Lance
>>
>> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
>>
>> I recently needed to re-implement multi-release lookup logic for a
>> [1]
>>
>> It occurred to me that JarFile.getVersionedEntry checks _every_ version
>> between 8 and the runtime version when looking up paths.
>>
>> Since META-INF/versions will probably be sparsely populated, I'm wondering
>> if something could be done to avoid checking 20 different paths in OpenJDK
>> 28.
>>
>> Perhaps scanning META-INF/versions once when opening the file could work,
>> then only check existing versions in getVersionedEntry?
>>
>> Maybe a premature optimization today, but with the new release cadence,
>> this problem is going to surface at some point in the future, right?
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>>
>> Eirik.
>>
>>
>>
>>
>>
>> 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  Sat Apr 11 21:36:21 2020
Date: Sat, 11 Apr 2020 23:36:21 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Hi Eirik,

interesting idea.

I think you could tune away a significant part of that up front cost by
this.stream().map(ZipEntry::getName). This will avoid expanding each
entry into a JarEntry internally. Perhaps this gets the up-front
overhead down to more acceptable levels..?

/Claes

On 2020-04-11 22:06, Eirik Bj?rsn?s wrote:
> There's an added up-front cost to scanning versions which I have also tried
> to test.
>
> Since checkForSpecialAttributes is lazy, this can be tested by measuring
> the time taken to read the first entry of an open JarFile. For the h2 jar
> file, this seems to take ~350 microseconds without my patch, which
> increases to ~850 microseconds with the patch.
>
> This cost applies to the first getEntry call and is then amortized over all
> following calls.
>
> So this patch is probably not a win for use cases where very few entries
>
> Eirik.
>
> On Sat, Apr 11, 2020 at 9:10 PM Eirik Bj?rsn?s  wrote:
>
>>
>> Lance,
>>
>> I made a small performance test. Pretty sloppy, so please don't tell
>> Aleksey S :-)
>>
>> Results indicate there may be some performance wins to be had.
>>
>> The test uses the Maven artifact com.h2database:h2:1.4.200:jar. This jar
>> which has 950 entries, of which the following three are versioned:
>>
>> META-INF/versions/10/org/h2/util/NetUtils2.class
>> META-INF/versions/9/org/h2/util/Bits.class
>> META-INF/versions/9/org/h2/util/CurrentTimestamp.class
>>
>> The performance test calls JarFile.getEntry for each of the base names
>> found in the jar. It does so 2000 times for 50 iterations and calculates
>> the average run time.
>>
>> This is done once on a JarFile opened with runtime version 15, once on a
>> JarFile opened with runtime version 8 (which effectively disables versioned
>> lookup so works as a baseline). Warmup runs are run first to get stable
>> results.
>>
>> The test is run with OpenJDK 15 built from master.
>>
>> Results:
>>
>> Average time to get 950 entries 2000 times:
>>
>> Runtime version 15: 2903 ms
>> Runtime version 8: 336 ms:
>>
>> This is shows the difference between testing seven versions (9, 10, 11,
>> 12, 13, 14, 15) and not testing versions.
>>
>> I then made a change to JarFile which scans the versions up front and
>> stores them in an int[] which is then looped over in getVersionedEntry.
>>
>> Results:
>>
>> Runtime version 15: 1048 ms
>> Runtime version 8: 315 ms:
>>
>> My benchmark is of course synthetic and does not represent reality. I have
>> not done any analysis on the shape of typical multi-versioned jars nor
>> their access patterns.
>>
>> However, an improvement of 2.5 - 3x is maybe worth taking a closer look?
>>
>> Here's the patch for my change in JarFile.java:
>>
>> Index: src/java.base/share/classes/java/util/jar/JarFile.java
>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> <+>UTF-8
>> ===================================================================
>> --- src/java.base/share/classes/java/util/jar/JarFile.java (revision
>> 86722cb038d3030c51f3268799a2c3dc0c508638)
>> +++ src/java.base/share/classes/java/util/jar/JarFile.java (date
>> 1586631626679)
>> @@ -161,7 +161,7 @@
>>       private final Runtime.Version version;  // current version
>>       private final int versionFeature;       // version.feature()
>>       private boolean isMultiRelease;         // is jar multi-release?
>> -
>> +    private int[] versions;                 // which versions does the
>> jar contain
>>       // indicates if Class-Path attribute present
>>       private boolean hasClassPathAttribute;
>>       // true if manifest checked for special attributes
>> @@ -599,12 +599,13 @@
>>       }
>>
>>       private JarEntry getVersionedEntry(String name, JarEntry je) {
>> -        if (BASE_VERSION_FEATURE < versionFeature) {
>> +        int[] versions = this.versions;
>> +        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
>> versions.length > 0) {
>>               if (!name.startsWith(META_INF)) {
>>                   // search for versioned entry
>> -                int v = versionFeature;
>> -                while (v > BASE_VERSION_FEATURE) {
>> -                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
>> "/" + name);
>> +                int v = versions.length - 1;
>> +                while (v >= 0) {
>> +                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
>> versions[v] + "/" + name);
>>                       if (vje != null) {
>>                           return vje.withBasename(name);
>>                       }
>> @@ -1016,9 +1017,20 @@
>>                           byte[] lbuf = new byte[512];
>>                           Attributes attr = new Attributes();
>> -                            new ByteArrayInputStream(b)), lbuf);
>> -                        isMultiRelease = Boolean.parseBoolean(
>> -                            attr.getValue(Attributes.Name.MULTI_RELEASE));
>> +                                new ByteArrayInputStream(b)), lbuf);
>> +                        if(Boolean.parseBoolean(
>> +
>>   attr.getValue(Attributes.Name.MULTI_RELEASE))) {
>> +                            isMultiRelease = true;
>> +                            versions = this.stream()
>> +                                    .map(ZipEntry::getName)
>> +                                    .mapToInt(this::parseVersion)
>> +                                    .filter(v -> v != -1 && v >=
>> BASE_VERSION_FEATURE && v <= versionFeature)
>> +                                    .distinct()
>> +                                    .sorted()
>> +                                    .toArray();
>> +
>> +                        }
>> +
>>                       }
>>                   }
>>               }
>> @@ -1026,6 +1038,27 @@
>>           }
>>       }
>>
>> +    /**
>> +     * If {@code entryName} is a a versioned entry, parse and return the
>> version as an integer, otherwise return -1
>> +     */
>> +    private int parseVersion(String entryName) {
>> +        if(!entryName.startsWith(META_INF_VERSIONS)) {
>> +            return -1;
>> +        }
>> +
>> +        int separator = entryName.indexOf("/",
>> META_INF_VERSIONS.length());
>> +
>> +        if(separator == -1) {
>> +            return -1;
>> +        }
>> +
>> +        try {
>> +            return Integer.parseInt(entryName,
>> META_INF_VERSIONS.length(), separator, 10);
>> +        } catch (NumberFormatException e) {
>> +            return -1;
>> +        }
>> +    }
>> +
>>       synchronized void ensureInitialization() {
>>           try {
>>               maybeInstantiateVerifier();
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen
>> wrote:
>>
>>> Hi Eric
>>>
>>> Feel free to enter a feature request and better yet propose a fix :-)
>>>
>>> Have a good weekend!
>>>
>>> Best
>>> Lance
>>>
>>> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
>>>
>>> I recently needed to re-implement multi-release lookup logic for a
>>> [1]
>>>
>>> It occurred to me that JarFile.getVersionedEntry checks _every_ version
>>> between 8 and the runtime version when looking up paths.
>>>
>>> Since META-INF/versions will probably be sparsely populated, I'm wondering
>>> if something could be done to avoid checking 20 different paths in OpenJDK
>>> 28.
>>>
>>> Perhaps scanning META-INF/versions once when opening the file could work,
>>> then only check existing versions in getVersionedEntry?
>>>
>>> Maybe a premature optimization today, but with the new release cadence,
>>> this problem is going to surface at some point in the future, right?
>>>
>>> [1]
>>> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>>>
>>> Eirik.
>>>
>>>
>>>
>>>
>>>
>>> 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 eirbjo at gmail.com  Sat Apr 11 21:54:26 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 11 Apr 2020 23:54:26 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID:

Claes,

That trick did occur to me before I reported the up front costs.

Without this optimization, my tests shows more like ~1050 microseconds

Perhaps further improvements is possible by extracting versions from the
binary representation instead of going via UTF for all names.

But I'm not sure it would be worth it. I don't feel I have a clear
understanding about how "bad" this up front cost really is compared to the
later wins in the real world.

Performance is hard to reason about :-)

Eirik.

On Sat, Apr 11, 2020 at 11:32 PM Claes Redestad
wrote:

> Hi Eirik,
>
> interesting idea.
>
> I think you could tune away a significant part of that up front cost by
> this.stream().map(ZipEntry::getName). This will avoid expanding each
> entry into a JarEntry internally. Perhaps this gets the up-front
> overhead down to more acceptable levels..?
>
> /Claes
>
> On 2020-04-11 22:06, Eirik Bj?rsn?s wrote:
> > There's an added up-front cost to scanning versions which I have also
> tried
> > to test.
> >
> > Since checkForSpecialAttributes is lazy, this can be tested by measuring
> > the time taken to read the first entry of an open JarFile. For the h2 jar
> > file, this seems to take ~350 microseconds without my patch, which
> > increases to ~850 microseconds with the patch.
> >
> > This cost applies to the first getEntry call and is then amortized over
> all
> > following calls.
> >
> > So this patch is probably not a win for use cases where very few entries
> >
> > Eirik.
> >
> > On Sat, Apr 11, 2020 at 9:10 PM Eirik Bj?rsn?s  wrote:
> >
> >>
> >> Lance,
> >>
> >> I made a small performance test. Pretty sloppy, so please don't tell
> >> Aleksey S :-)
> >>
> >> Results indicate there may be some performance wins to be had.
> >>
> >> The test uses the Maven artifact com.h2database:h2:1.4.200:jar. This jar
> >> which has 950 entries, of which the following three are versioned:
> >>
> >> META-INF/versions/10/org/h2/util/NetUtils2.class
> >> META-INF/versions/9/org/h2/util/Bits.class
> >> META-INF/versions/9/org/h2/util/CurrentTimestamp.class
> >>
> >> The performance test calls JarFile.getEntry for each of the base names
> >> found in the jar. It does so 2000 times for 50 iterations and calculates
> >> the average run time.
> >>
> >> This is done once on a JarFile opened with runtime version 15, once on a
> >> JarFile opened with runtime version 8 (which effectively disables
> versioned
> >> lookup so works as a baseline). Warmup runs are run first to get stable
> >> results.
> >>
> >> The test is run with OpenJDK 15 built from master.
> >>
> >> Results:
> >>
> >> Average time to get 950 entries 2000 times:
> >>
> >> Runtime version 15: 2903 ms
> >> Runtime version 8: 336 ms:
> >>
> >> This is shows the difference between testing seven versions (9, 10, 11,
> >> 12, 13, 14, 15) and not testing versions.
> >>
> >> I then made a change to JarFile which scans the versions up front and
> >> stores them in an int[] which is then looped over in getVersionedEntry.
> >>
> >> Results:
> >>
> >> Runtime version 15: 1048 ms
> >> Runtime version 8: 315 ms:
> >>
> >> My benchmark is of course synthetic and does not represent reality. I
> have
> >> not done any analysis on the shape of typical multi-versioned jars nor
> >> their access patterns.
> >>
> >> However, an improvement of 2.5 - 3x is maybe worth taking a closer look?
> >>
> >> Here's the patch for my change in JarFile.java:
> >>
> >> Index: src/java.base/share/classes/java/util/jar/JarFile.java
> >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> >> <+>UTF-8
> >> ===================================================================
> >> --- src/java.base/share/classes/java/util/jar/JarFile.java (revision
> >> 86722cb038d3030c51f3268799a2c3dc0c508638)
> >> +++ src/java.base/share/classes/java/util/jar/JarFile.java (date
> >> 1586631626679)
> >> @@ -161,7 +161,7 @@
> >>       private final Runtime.Version version;  // current version
> >>       private final int versionFeature;       // version.feature()
> >>       private boolean isMultiRelease;         // is jar multi-release?
> >> -
> >> +    private int[] versions;                 // which versions does the
> >> jar contain
> >>       // indicates if Class-Path attribute present
> >>       private boolean hasClassPathAttribute;
> >>       // true if manifest checked for special attributes
> >> @@ -599,12 +599,13 @@
> >>       }
> >>
> >>       private JarEntry getVersionedEntry(String name, JarEntry je) {
> >> -        if (BASE_VERSION_FEATURE < versionFeature) {
> >> +        int[] versions = this.versions;
> >> +        if (BASE_VERSION_FEATURE < versionFeature && versions != null
> &&
> >> versions.length > 0) {
> >>               if (!name.startsWith(META_INF)) {
> >>                   // search for versioned entry
> >> -                int v = versionFeature;
> >> -                while (v > BASE_VERSION_FEATURE) {
> >> -                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v
> +
> >> "/" + name);
> >> +                int v = versions.length - 1;
> >> +                while (v >= 0) {
> >> +                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
> >> versions[v] + "/" + name);
> >>                       if (vje != null) {
> >>                           return vje.withBasename(name);
> >>                       }
> >> @@ -1016,9 +1017,20 @@
> >>                           byte[] lbuf = new byte[512];
> >>                           Attributes attr = new Attributes();
> >> -                            new ByteArrayInputStream(b)), lbuf);
> >> -                        isMultiRelease = Boolean.parseBoolean(
> >> -
> attr.getValue(Attributes.Name.MULTI_RELEASE));
> >> +                                new ByteArrayInputStream(b)), lbuf);
> >> +                        if(Boolean.parseBoolean(
> >> +
> >>   attr.getValue(Attributes.Name.MULTI_RELEASE))) {
> >> +                            isMultiRelease = true;
> >> +                            versions = this.stream()
> >> +                                    .map(ZipEntry::getName)
> >> +                                    .mapToInt(this::parseVersion)
> >> +                                    .filter(v -> v != -1 && v >=
> >> BASE_VERSION_FEATURE && v <= versionFeature)
> >> +                                    .distinct()
> >> +                                    .sorted()
> >> +                                    .toArray();
> >> +
> >> +                        }
> >> +
> >>                       }
> >>                   }
> >>               }
> >> @@ -1026,6 +1038,27 @@
> >>           }
> >>       }
> >>
> >> +    /**
> >> +     * If {@code entryName} is a a versioned entry, parse and return
> the
> >> version as an integer, otherwise return -1
> >> +     */
> >> +    private int parseVersion(String entryName) {
> >> +        if(!entryName.startsWith(META_INF_VERSIONS)) {
> >> +            return -1;
> >> +        }
> >> +
> >> +        int separator = entryName.indexOf("/",
> >> META_INF_VERSIONS.length());
> >> +
> >> +        if(separator == -1) {
> >> +            return -1;
> >> +        }
> >> +
> >> +        try {
> >> +            return Integer.parseInt(entryName,
> >> META_INF_VERSIONS.length(), separator, 10);
> >> +        } catch (NumberFormatException e) {
> >> +            return -1;
> >> +        }
> >> +    }
> >> +
> >>       synchronized void ensureInitialization() {
> >>           try {
> >>               maybeInstantiateVerifier();
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen <
> lance.andersen at oracle.com>
> >> wrote:
> >>
> >>> Hi Eric
> >>>
> >>> Feel free to enter a feature request and better yet propose a fix :-)
> >>>
> >>> Have a good weekend!
> >>>
> >>> Best
> >>> Lance
> >>>
> >>> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
> >>>
> >>> I recently needed to re-implement multi-release lookup logic for a
> files
> >>> [1]
> >>>
> >>> It occurred to me that JarFile.getVersionedEntry checks _every_ version
> >>> between 8 and the runtime version when looking up paths.
> >>>
> >>> Since META-INF/versions will probably be sparsely populated, I'm
> wondering
> >>> if something could be done to avoid checking 20 different paths in
> OpenJDK
> >>> 28.
> >>>
> >>> Perhaps scanning META-INF/versions once when opening the file could
> work,
> >>> then only check existing versions in getVersionedEntry?
> >>>
> >>> Maybe a premature optimization today, but with the new release cadence,
> >>> this problem is going to surface at some point in the future, right?
> >>>
> >>> [1]
> >>>
> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
> >>>
> >>> Eirik.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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 eirbjo at gmail.com  Sat Apr 11 22:03:34 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 12 Apr 2020 00:03:34 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID:

If Multi-Release specified a list of versions instead if just true|false,
then scanning would not be needed at all.

Would require a spec update and updates to ecosystem build tools etc, but
perhaps a better choice in the long run since any kind of scanning will be
linear to to number of entries.

Eirik.

On Sat, Apr 11, 2020 at 11:54 PM Eirik Bj?rsn?s  wrote:

> Claes,
>
> That trick did occur to me before I reported the up front costs.
>
> Without this optimization, my tests shows more like ~1050 microseconds
>
> Perhaps further improvements is possible by extracting versions from the
> binary representation instead of going via UTF for all names.
>
> But I'm not sure it would be worth it. I don't feel I have a clear
> understanding about how "bad" this up front cost really is compared to the
> later wins in the real world.
>
> Performance is hard to reason about :-)
>
> Eirik.
>
> On Sat, Apr 11, 2020 at 11:32 PM Claes Redestad
> wrote:
>
>> Hi Eirik,
>>
>> interesting idea.
>>
>> I think you could tune away a significant part of that up front cost by
>> this.stream().map(ZipEntry::getName). This will avoid expanding each
>> entry into a JarEntry internally. Perhaps this gets the up-front
>> overhead down to more acceptable levels..?
>>
>> /Claes
>>
>> On 2020-04-11 22:06, Eirik Bj?rsn?s wrote:
>> > There's an added up-front cost to scanning versions which I have also
>> tried
>> > to test.
>> >
>> > Since checkForSpecialAttributes is lazy, this can be tested by measuring
>> > the time taken to read the first entry of an open JarFile. For the h2
>> jar
>> > file, this seems to take ~350 microseconds without my patch, which
>> > increases to ~850 microseconds with the patch.
>> >
>> > This cost applies to the first getEntry call and is then amortized over
>> all
>> > following calls.
>> >
>> > So this patch is probably not a win for use cases where very few entries
>> >
>> > Eirik.
>> >
>> > On Sat, Apr 11, 2020 at 9:10 PM Eirik Bj?rsn?s
>> wrote:
>> >
>> >>
>> >> Lance,
>> >>
>> >> I made a small performance test. Pretty sloppy, so please don't tell
>> >> Aleksey S :-)
>> >>
>> >> Results indicate there may be some performance wins to be had.
>> >>
>> >> The test uses the Maven artifact com.h2database:h2:1.4.200:jar. This
>> jar
>> >> which has 950 entries, of which the following three are versioned:
>> >>
>> >> META-INF/versions/10/org/h2/util/NetUtils2.class
>> >> META-INF/versions/9/org/h2/util/Bits.class
>> >> META-INF/versions/9/org/h2/util/CurrentTimestamp.class
>> >>
>> >> The performance test calls JarFile.getEntry for each of the base names
>> >> found in the jar. It does so 2000 times for 50 iterations and
>> calculates
>> >> the average run time.
>> >>
>> >> This is done once on a JarFile opened with runtime version 15, once on
>> a
>> >> JarFile opened with runtime version 8 (which effectively disables
>> versioned
>> >> lookup so works as a baseline). Warmup runs are run first to get stable
>> >> results.
>> >>
>> >> The test is run with OpenJDK 15 built from master.
>> >>
>> >> Results:
>> >>
>> >> Average time to get 950 entries 2000 times:
>> >>
>> >> Runtime version 15: 2903 ms
>> >> Runtime version 8: 336 ms:
>> >>
>> >> This is shows the difference between testing seven versions (9, 10, 11,
>> >> 12, 13, 14, 15) and not testing versions.
>> >>
>> >> I then made a change to JarFile which scans the versions up front and
>> >> stores them in an int[] which is then looped over in getVersionedEntry.
>> >>
>> >> Results:
>> >>
>> >> Runtime version 15: 1048 ms
>> >> Runtime version 8: 315 ms:
>> >>
>> >> My benchmark is of course synthetic and does not represent reality. I
>> have
>> >> not done any analysis on the shape of typical multi-versioned jars nor
>> >> their access patterns.
>> >>
>> >> However, an improvement of 2.5 - 3x is maybe worth taking a closer
>> look?
>> >>
>> >> Here's the patch for my change in JarFile.java:
>> >>
>> >> Index: src/java.base/share/classes/java/util/jar/JarFile.java
>> >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> >> <+>UTF-8
>> >> ===================================================================
>> >> --- src/java.base/share/classes/java/util/jar/JarFile.java (revision
>> >> 86722cb038d3030c51f3268799a2c3dc0c508638)
>> >> +++ src/java.base/share/classes/java/util/jar/JarFile.java (date
>> >> 1586631626679)
>> >> @@ -161,7 +161,7 @@
>> >>       private final Runtime.Version version;  // current version
>> >>       private final int versionFeature;       // version.feature()
>> >>       private boolean isMultiRelease;         // is jar multi-release?
>> >> -
>> >> +    private int[] versions;                 // which versions does the
>> >> jar contain
>> >>       // indicates if Class-Path attribute present
>> >>       private boolean hasClassPathAttribute;
>> >>       // true if manifest checked for special attributes
>> >> @@ -599,12 +599,13 @@
>> >>       }
>> >>
>> >>       private JarEntry getVersionedEntry(String name, JarEntry je) {
>> >> -        if (BASE_VERSION_FEATURE < versionFeature) {
>> >> +        int[] versions = this.versions;
>> >> +        if (BASE_VERSION_FEATURE < versionFeature && versions != null
>> &&
>> >> versions.length > 0) {
>> >>               if (!name.startsWith(META_INF)) {
>> >>                   // search for versioned entry
>> >> -                int v = versionFeature;
>> >> -                while (v > BASE_VERSION_FEATURE) {
>> >> -                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
>> v +
>> >> "/" + name);
>> >> +                int v = versions.length - 1;
>> >> +                while (v >= 0) {
>> >> +                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
>> >> versions[v] + "/" + name);
>> >>                       if (vje != null) {
>> >>                           return vje.withBasename(name);
>> >>                       }
>> >> @@ -1016,9 +1017,20 @@
>> >>                           byte[] lbuf = new byte[512];
>> >>                           Attributes attr = new Attributes();
>> >> -                            new ByteArrayInputStream(b)), lbuf);
>> >> -                        isMultiRelease = Boolean.parseBoolean(
>> >> -
>> attr.getValue(Attributes.Name.MULTI_RELEASE));
>> >> +                                new ByteArrayInputStream(b)), lbuf);
>> >> +                        if(Boolean.parseBoolean(
>> >> +
>> >>   attr.getValue(Attributes.Name.MULTI_RELEASE))) {
>> >> +                            isMultiRelease = true;
>> >> +                            versions = this.stream()
>> >> +                                    .map(ZipEntry::getName)
>> >> +                                    .mapToInt(this::parseVersion)
>> >> +                                    .filter(v -> v != -1 && v >=
>> >> BASE_VERSION_FEATURE && v <= versionFeature)
>> >> +                                    .distinct()
>> >> +                                    .sorted()
>> >> +                                    .toArray();
>> >> +
>> >> +                        }
>> >> +
>> >>                       }
>> >>                   }
>> >>               }
>> >> @@ -1026,6 +1038,27 @@
>> >>           }
>> >>       }
>> >>
>> >> +    /**
>> >> +     * If {@code entryName} is a a versioned entry, parse and return
>> the
>> >> version as an integer, otherwise return -1
>> >> +     */
>> >> +    private int parseVersion(String entryName) {
>> >> +        if(!entryName.startsWith(META_INF_VERSIONS)) {
>> >> +            return -1;
>> >> +        }
>> >> +
>> >> +        int separator = entryName.indexOf("/",
>> >> META_INF_VERSIONS.length());
>> >> +
>> >> +        if(separator == -1) {
>> >> +            return -1;
>> >> +        }
>> >> +
>> >> +        try {
>> >> +            return Integer.parseInt(entryName,
>> >> META_INF_VERSIONS.length(), separator, 10);
>> >> +        } catch (NumberFormatException e) {
>> >> +            return -1;
>> >> +        }
>> >> +    }
>> >> +
>> >>       synchronized void ensureInitialization() {
>> >>           try {
>> >>               maybeInstantiateVerifier();
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen <
>> lance.andersen at oracle.com>
>> >> wrote:
>> >>
>> >>> Hi Eric
>> >>>
>> >>> Feel free to enter a feature request and better yet propose a fix :-)
>> >>>
>> >>> Have a good weekend!
>> >>>
>> >>> Best
>> >>> Lance
>> >>>
>> >>> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s  wrote:
>> >>>
>> >>> I recently needed to re-implement multi-release lookup logic for a
>> files
>> >>> [1]
>> >>>
>> >>> It occurred to me that JarFile.getVersionedEntry checks _every_
>> version
>> >>> between 8 and the runtime version when looking up paths.
>> >>>
>> >>> Since META-INF/versions will probably be sparsely populated, I'm
>> wondering
>> >>> if something could be done to avoid checking 20 different paths in
>> OpenJDK
>> >>> 28.
>> >>>
>> >>> Perhaps scanning META-INF/versions once when opening the file could
>> work,
>> >>> then only check existing versions in getVersionedEntry?
>> >>>
>> >>> Maybe a premature optimization today, but with the new release
>> >>> this problem is going to surface at some point in the future, right?
>> >>>
>> >>> [1]
>> >>>
>> https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>> >>>
>> >>> Eirik.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 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  Sat Apr 11 22:24:39 2020
Date: Sun, 12 Apr 2020 00:24:39 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID: <6818fb60-0027-60df-0439-39e668f16273@oracle.com>

Agree that declaring which versions are available in a manifest
attribute would be the best solution from a performance point of view,
since there'd be no scanning at all. Seems like an optional attribute
that should be relatively easy to add and cause no adverse effects on
unaware JDK versions.

/Claes

On 2020-04-12 00:03, Eirik Bj?rsn?s wrote:
>
> If?Multi-Release specified a list of versions instead if just
> true|false, then scanning would not be needed at all.
>
> Would require a spec update and updates to ecosystem build tools etc,
> but perhaps a better choice in the long run since any kind of scanning
> will be linear to to number of entries.
>
> Eirik.
>
> On Sat, Apr 11, 2020 at 11:54 PM Eirik Bj?rsn?s  > wrote:
>
>     Claes,
>
>     That trick did occur to me before I reported the up front costs.
>
>     Without this optimization, my tests shows more like ~1050
>
>     Perhaps further improvements is possible by extracting versions from
>     the binary representation instead of going via UTF for all names.
>
>     But I'm not sure it would be worth it. I don't feel I have a clear
>     understanding about how "bad" this up front cost really is compared
>     to the later wins in the real world.
>
>     Performance is hard to reason about :-)
>
>     Eirik.
>
>     On Sat, Apr 11, 2020 at 11:32 PM Claes Redestad
>     > wrote:
>
>         Hi Eirik,
>
>         interesting idea.
>
>         I think you could tune away a significant part of that up front
>         cost by
>         this.stream().map(ZipEntry::getName). This will avoid expanding each
>         entry into a JarEntry internally. Perhaps this gets the up-front
>         overhead down to more acceptable levels..?
>
>         /Claes
>
>         On 2020-04-11 22:06, Eirik Bj?rsn?s wrote:
>          > There's an added up-front cost to scanning versions which I
>         have also tried
>          > to test.
>          >
>          > Since checkForSpecialAttributes is lazy, this can be tested
>         by measuring
>          > the time taken to read the first entry of an open JarFile.
>         For the h2 jar
>          > file, this seems to take ~350 microseconds without my patch,
>         which
>          > increases to ~850 microseconds with the patch.
>          >
>          > This cost applies to the first getEntry call and is then
>         amortized over all
>          > following calls.
>          >
>          > So this patch is probably not a win for use cases where very
>         few entries
>          >
>          > Eirik.
>          >
>          > On Sat, Apr 11, 2020 at 9:10 PM Eirik Bj?rsn?s
>         > wrote:
>          >
>          >>
>          >> Lance,
>          >>
>          >> I made a small performance test. Pretty sloppy, so please
>         don't tell
>          >> Aleksey S :-)
>          >>
>          >> Results indicate there may be some performance wins to be had.
>          >>
>          >> The test uses the Maven artifact
>         com.h2database:h2:1.4.200:jar. This jar
>          >> which has 950 entries, of which the following three are
>         versioned:
>          >>
>          >> META-INF/versions/10/org/h2/util/NetUtils2.class
>          >> META-INF/versions/9/org/h2/util/Bits.class
>          >> META-INF/versions/9/org/h2/util/CurrentTimestamp.class
>          >>
>          >> The performance test calls JarFile.getEntry for each of the
>         base names
>          >> found in the jar. It does so 2000 times for 50 iterations
>         and calculates
>          >> the average run time.
>          >>
>          >> This is done once on a JarFile opened with runtime version
>         15, once on a
>          >> JarFile opened with runtime version 8 (which effectively
>         disables versioned
>          >> lookup so works as a baseline). Warmup runs are run first to
>         get stable
>          >> results.
>          >>
>          >> The test is run with OpenJDK 15 built from master.
>          >>
>          >> Results:
>          >>
>          >> Average time to get 950 entries 2000 times:
>          >>
>          >> Runtime version 15: 2903 ms
>          >> Runtime version 8: 336 ms:
>          >>
>          >> This is shows the difference between testing seven versions
>         (9, 10, 11,
>          >> 12, 13, 14, 15) and not testing versions.
>          >>
>          >> I then made a change to JarFile which scans the versions up
>         front and
>          >> stores them in an int[] which is then looped over in
>         getVersionedEntry.
>          >>
>          >> Results:
>          >>
>          >> Runtime version 15: 1048 ms
>          >> Runtime version 8: 315 ms:
>          >>
>          >> My benchmark is of course synthetic and does not represent
>         reality. I have
>          >> not done any analysis on the shape of typical
>         multi-versioned jars nor
>          >> their access patterns.
>          >>
>          >> However, an improvement of 2.5 - 3x is maybe worth taking a
>         closer look?
>          >>
>          >> Here's the patch for my change in JarFile.java:
>          >>
>          >> Index: src/java.base/share/classes/java/util/jar/JarFile.java
>          >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>          >> <+>UTF-8
>          >>
>         ===================================================================
>          >> --- src/java.base/share/classes/java/util/jar/JarFile.java
>         (revision
>          >> 86722cb038d3030c51f3268799a2c3dc0c508638)
>          >> +++ src/java.base/share/classes/java/util/jar/JarFile.java (date
>          >> 1586631626679)
>          >> @@ -161,7 +161,7 @@
>          >>? ? ? ?private final Runtime.Version version;? // current version
>          >>? ? ? ?private final int versionFeature;? ? ? ?//
>         version.feature()
>          >>? ? ? ?private boolean isMultiRelease;? ? ? ? ?// is jar
>         multi-release?
>          >> -
>          >> +? ? private int[] versions;? ? ? ? ? ? ? ? ?// which
>         versions does the
>          >> jar contain
>          >>? ? ? ?// indicates if Class-Path attribute present
>          >>? ? ? ?private boolean hasClassPathAttribute;
>          >>? ? ? ?// true if manifest checked for special attributes
>          >> @@ -599,12 +599,13 @@
>          >>? ? ? ?}
>          >>
>          >>? ? ? ?private JarEntry getVersionedEntry(String name,
>         JarEntry je) {
>          >> -? ? ? ? if (BASE_VERSION_FEATURE < versionFeature) {
>          >> +? ? ? ? int[] versions = this.versions;
>          >> +? ? ? ? if (BASE_VERSION_FEATURE < versionFeature &&
>         versions != null &&
>          >> versions.length > 0) {
>          >>? ? ? ? ? ? ? ?if (!name.startsWith(META_INF)) {
>          >>? ? ? ? ? ? ? ? ? ?// search for versioned entry
>          >> -? ? ? ? ? ? ? ? int v = versionFeature;
>          >> -? ? ? ? ? ? ? ? while (v > BASE_VERSION_FEATURE) {
>          >> -? ? ? ? ? ? ? ? ? ? JarFileEntry vje =
>         getEntry0(META_INF_VERSIONS + v +
>          >> "/" + name);
>          >> +? ? ? ? ? ? ? ? int v = versions.length - 1;
>          >> +? ? ? ? ? ? ? ? while (v >= 0) {
>          >> +? ? ? ? ? ? ? ? ? ? JarFileEntry vje =
>         getEntry0(META_INF_VERSIONS +
>          >> versions[v] + "/" + name);
>          >>? ? ? ? ? ? ? ? ? ? ? ?if (vje != null) {
>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?return vje.withBasename(name);
>          >>? ? ? ? ? ? ? ? ? ? ? ?}
>          >> @@ -1016,9 +1017,20 @@
>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?byte[] lbuf = new byte[512];
>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?Attributes attr = new Attributes();
>          >>? ? ? ? ? ? ? ? ? ? ? ? ? ?attr.read(new
>         Manifest.FastInputStream(
>          >> -? ? ? ? ? ? ? ? ? ? ? ? ? ? new ByteArrayInputStream(b)),
>         lbuf);
>          >> -? ? ? ? ? ? ? ? ? ? ? ? isMultiRelease = Boolean.parseBoolean(
>          >> -
>         attr.getValue(Attributes.Name.MULTI_RELEASE));
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new
>         ByteArrayInputStream(b)), lbuf);
>          >> +? ? ? ? ? ? ? ? ? ? ? ? if(Boolean.parseBoolean(
>          >> +
>          >>? ?attr.getValue(Attributes.Name.MULTI_RELEASE))) {
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? isMultiRelease = true;
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? versions = this.stream()
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .map(ZipEntry::getName)
>          >> +
>         .mapToInt(this::parseVersion)
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(v -> v != -1 &&
>         v >=
>          >> BASE_VERSION_FEATURE && v <= versionFeature)
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .distinct()
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .sorted()
>          >> +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .toArray();
>          >> +
>          >> +? ? ? ? ? ? ? ? ? ? ? ? }
>          >> +
>          >>? ? ? ? ? ? ? ? ? ? ? ?}
>          >>? ? ? ? ? ? ? ? ? ?}
>          >>? ? ? ? ? ? ? ?}
>          >> @@ -1026,6 +1038,27 @@
>          >>? ? ? ? ? ?}
>          >>? ? ? ?}
>          >>
>          >> +? ? /**
>          >> +? ? ?* If {@code entryName} is a a versioned entry, parse
>         and return the
>          >> version as an integer, otherwise return -1
>          >> +? ? ?*/
>          >> +? ? private int parseVersion(String entryName) {
>          >> +? ? ? ? if(!entryName.startsWith(META_INF_VERSIONS)) {
>          >> +? ? ? ? ? ? return -1;
>          >> +? ? ? ? }
>          >> +
>          >> +? ? ? ? int separator = entryName.indexOf("/",
>          >> META_INF_VERSIONS.length());
>          >> +
>          >> +? ? ? ? if(separator == -1) {
>          >> +? ? ? ? ? ? return -1;
>          >> +? ? ? ? }
>          >> +
>          >> +? ? ? ? try {
>          >> +? ? ? ? ? ? return Integer.parseInt(entryName,
>          >> META_INF_VERSIONS.length(), separator, 10);
>          >> +? ? ? ? } catch (NumberFormatException e) {
>          >> +? ? ? ? ? ? return -1;
>          >> +? ? ? ? }
>          >> +? ? }
>          >> +
>          >>? ? ? ?synchronized void ensureInitialization() {
>          >>? ? ? ? ? ?try {
>          >>? ? ? ? ? ? ? ?maybeInstantiateVerifier();
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >>
>          >> On Fri, Apr 10, 2020 at 10:58 PM Lance Andersen
>         >
>          >> wrote:
>          >>
>          >>> Hi Eric
>          >>>
>          >>> Feel free to enter a feature request and better yet propose
>         a fix :-)
>          >>>
>          >>> Have a good weekend!
>          >>>
>          >>> Best
>          >>> Lance
>          >>>
>          >>> On Apr 10, 2020, at 2:59 PM, Eirik Bj?rsn?s
>         > wrote:
>          >>>
>          >>> I recently needed to re-implement multi-release lookup
>         logic for a
>         (exploded) jar files
>          >>> [1]
>          >>>
>          >>> It occurred to me that JarFile.getVersionedEntry checks
>         _every_ version
>          >>> between 8 and the runtime version when looking up paths.
>          >>>
>          >>> Since META-INF/versions will probably be sparsely
>         populated, I'm wondering
>          >>> if something could be done to avoid checking 20 different
>         paths in OpenJDK
>          >>> 28.
>          >>>
>          >>> Perhaps scanning META-INF/versions once when opening the
>         file could work,
>          >>> then only check existing versions in getVersionedEntry?
>          >>>
>          >>> Maybe a premature optimization today, but with the new
>          >>> this problem is going to surface at some point in the
>         future, right?
>          >>>
>          >>> [1]
>          >>>
>         https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html
>          >>>
>          >>> Eirik.
>          >>>
>          >>>
>          >>>
>          >>>
>          >>>
>          >>>
>         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 mandy.chung at oracle.com  Sun Apr 12 03:13:07 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 11 Apr 2020 20:13:07 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
<1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>
Message-ID:

http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/

Incremental specdiff:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
This is to follow a discussion [1] on Class::descriptorString and
MethodType::descriptorString for hidden classes.?? The proposal is to
define the descriptor string for a hidden class of this form:
??? "L" + N + ";" + "/" +

The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
`MethodType::descriptorString` are updated to return the descriptor of
this form for a hidden class.?? To support hidden class,
`java.lang.invoke.TypeDescriptor` spec is revised such that a
`TypeDescriptor` object can represent an entity that may not be
described in nominal form. ??? This change affects JVM TI, JDWP and
JDI.??? The spec change includes a couple other JVM TI and
java.instrument spec clarification w.r.t. hidden classes that Serguei
has been working on.

Mandy
[1]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html

----------------
As a record, the above patch is applied on the top:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/

webrev.06 includes the following changes that have been reviewed:
1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden
2. remove unused `setImplMethod` method from lambda proxy class
3. include Serguei's patch to fix JDK-8242166: regression in JDI
4. drop the uniqueness guarantee of the suffix of the hidden class's name

On 3/31/20 8:01 PM, Mandy Chung wrote:
> Thanks to the review feedbacks.
>
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/
>
> Delta between webrev.03 and webrev.04:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/
>
>
> Summary of changes is:
> 1. Update javac to retain the previous behavior when compiling to
> target release <= 14 where lambda proxy class is not a nestmate
> 2. Rename Class::isHiddenClass to Class::isHidden
> 3. Address Joe's feedback on the CSR to document the behavior of the
> relevant methods in java.lang.Class for hidden classes
> 4. Add test case for unloadable class with nest host error
> 5. Add test cases for hidden classes with different kinds of class or
> interface
> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class"
> 7. Small changes in response to Remi, Coleen, Paul's review comments
> 9. Fix @modules in tests
>
> Most of the changes above have also been reviewed as separate patches.
>
> Thanks
> Mandy
>
> On 3/26/20 4:57 PM, Mandy Chung wrote:
>> Please review the implementation of JEP 371: Hidden Classes. The main
>> changes are in core-libs and hotspot runtime area.? Small changes are
>> made in javac, VM compiler (intrinsification of
>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed
>> and is in the finalized state (see specdiff and javadoc below for
>> reference).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
>>
>>
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
>>
>>
>> JVMS 5.4.4 change:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
>>
>>
>> CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>
>> Thanks
>> Mandy
>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502
>

From eirbjo at gmail.com  Sun Apr 12 08:50:20 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 12 Apr 2020 10:50:20 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID:

>
> I think you could tune away a significant part of that up front cost by
> this.stream().map(ZipEntry::getName). This will avoid expanding each
> entry into a JarEntry internally. Perhaps this gets the up-front
> overhead down to more acceptable levels..?
>

I found JUZFA.getMetaInfEntryNames which made the up front scanning
cost evaporate.

Should be fast for other jars as well, at least when META-INF/ is sparsely
populated.

Here's an updated patch:

diff --git a/src/java.base/share/classes/java/util/jar/JarFile.java
b/src/java.base/share/classes/java/util/jar/JarFile.java
index 1ec0f5bdae..95472604c0 100644
--- a/src/java.base/share/classes/java/util/jar/JarFile.java
+++ b/src/java.base/share/classes/java/util/jar/JarFile.java
@@ -161,7 +161,7 @@ public class JarFile extends ZipFile {
private final Runtime.Version version;  // current version
private final int versionFeature;       // version.feature()
private boolean isMultiRelease;         // is jar multi-release?
-
+    private int[] versions;                 // which versions does the jar
contain
// indicates if Class-Path attribute present
private boolean hasClassPathAttribute;
// true if manifest checked for special attributes
@@ -599,12 +599,13 @@ public class JarFile extends ZipFile {
}

private JarEntry getVersionedEntry(String name, JarEntry je) {
-        if (BASE_VERSION_FEATURE < versionFeature) {
+        int[] versions = this.versions;
+        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
versions.length > 0) {
if (!name.startsWith(META_INF)) {
// search for versioned entry
-                int v = versionFeature;
-                while (v > BASE_VERSION_FEATURE) {
-                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
"/" + name);
+                int v = versions.length - 1;
+                while (v >= 0) {
+                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
versions[v] + "/" + name);
if (vje != null) {
return vje.withBasename(name);
}
@@ -1016,9 +1017,18 @@ public class JarFile extends ZipFile {
byte[] lbuf = new byte[512];
Attributes attr = new Attributes();
-                            new ByteArrayInputStream(b)), lbuf);
-                        isMultiRelease = Boolean.parseBoolean(
-                            attr.getValue(Attributes.Name.MULTI_RELEASE));
+                                new ByteArrayInputStream(b)), lbuf);
+                        if(Boolean.parseBoolean(
+
attr.getValue(Attributes.Name.MULTI_RELEASE))) {
+                            isMultiRelease = true;
+                            versions =
Stream.of(JUZFA.getMetaInfEntryNames(this))
+                                    .mapToInt(this::parseVersion)
+                                    .filter(v -> v != -1 && v >=
BASE_VERSION_FEATURE && v <= versionFeature)
+                                    .distinct()
+                                    .sorted()
+                                    .toArray();
+                        }
+
}
}
}
@@ -1026,6 +1036,27 @@ public class JarFile extends ZipFile {
}
}

+    /**
+     * If {@code entryName} is a a versioned entry, parse and return the
version as an integer, otherwise return -1
+     */
+    private int parseVersion(String entryName) {
+        if(!entryName.startsWith(META_INF_VERSIONS)) {
+            return -1;
+        }
+
+        int separator = entryName.indexOf("/", META_INF_VERSIONS.length());
+
+        if(separator == -1) {
+            return -1;
+        }
+
+        try {
+            return Integer.parseInt(entryName, META_INF_VERSIONS.length(),
separator, 10);
+        } catch (NumberFormatException e) {
+            return -1;
+        }
+    }
+
synchronized void ensureInitialization() {
try {
maybeInstantiateVerifier();

Eirik.

From eirbjo at gmail.com  Sun Apr 12 11:26:11 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 12 Apr 2020 13:26:11 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID:

Claes,

Since the ZIP index is already scanned for META-INF/ names in
ZipFile.Source.initCEN, it might make sense to move version scanning there.
This would also allow identifying version strings at the byte array level.

Here's a patch which implements this:

diff --git a/src/java.base/share/classes/java/util/jar/JarFile.java
b/src/java.base/share/classes/java/util/jar/JarFile.java
index 1ec0f5bdae..988cc837f0 100644
--- a/src/java.base/share/classes/java/util/jar/JarFile.java
+++ b/src/java.base/share/classes/java/util/jar/JarFile.java
@@ -49,6 +49,7 @@ import java.util.Locale;
import java.util.NoSuchElementException;
import java.util.Objects;
import java.util.function.Function;
+import java.util.stream.IntStream;
import java.util.stream.Stream;
import java.util.zip.ZipEntry;
import java.util.zip.ZipException;
@@ -161,7 +162,7 @@ public class JarFile extends ZipFile {
private final Runtime.Version version;  // current version
private final int versionFeature;       // version.feature()
private boolean isMultiRelease;         // is jar multi-release?
-
+    private int[] versions;                 // which versions does the jar
contain
// indicates if Class-Path attribute present
private boolean hasClassPathAttribute;
// true if manifest checked for special attributes
@@ -599,12 +600,13 @@ public class JarFile extends ZipFile {
}

private JarEntry getVersionedEntry(String name, JarEntry je) {
-        if (BASE_VERSION_FEATURE < versionFeature) {
+        int[] versions = this.versions;
+        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
versions.length > 0) {
if (!name.startsWith(META_INF)) {
// search for versioned entry
-                int v = versionFeature;
-                while (v > BASE_VERSION_FEATURE) {
-                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
"/" + name);
+                int v = versions.length - 1;
+                while (v >= 0) {
+                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
versions[v] + "/" + name);
if (vje != null) {
return vje.withBasename(name);
}
@@ -1016,9 +1018,16 @@ public class JarFile extends ZipFile {
byte[] lbuf = new byte[512];
Attributes attr = new Attributes();
-                            new ByteArrayInputStream(b)), lbuf);
-                        isMultiRelease = Boolean.parseBoolean(
-                            attr.getValue(Attributes.Name.MULTI_RELEASE));
+                                new ByteArrayInputStream(b)), lbuf);
+                        if(Boolean.parseBoolean(
+
attr.getValue(Attributes.Name.MULTI_RELEASE))) {
+                            isMultiRelease = true;
+                            versions =
IntStream.of(JUZFA.getMetaInfVersions(this))
+                                    .filter(v -> v >= BASE_VERSION_FEATURE
&& v <= versionFeature)
+                                    .sorted()
+                                    .toArray();
+                        }
+
}
}
}
diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
b/src/java.base/share/classes/java/util/zip/ZipFile.java
index 274e8788d1..25eeb57555 100644
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
@@ -48,6 +48,7 @@ import java.util.Iterator;
import java.util.Objects;
import java.util.NoSuchElementException;
import java.util.Set;
+import java.util.HashSet;
import java.util.Spliterator;
import java.util.Spliterators;
import java.util.WeakHashMap;
@@ -1063,6 +1064,11 @@ public class ZipFile implements ZipConstants,
Closeable {
return zip.getMetaInfEntryNames();
}
@Override
+                public int[] getMetaInfVersions(ZipFile zip) {
+                    final int[] metaVersions = zip.res.zsrc.metaVersions;
+                    return metaVersions == null ? new int[0] :
metaVersions;
+                }
+                @Override
public JarEntry getEntry(ZipFile zip, String name,
Function func) {
return (JarEntry)zip.getEntry(name, func);
@@ -1097,6 +1103,7 @@ public class ZipFile implements ZipConstants,
Closeable {
private byte[] comment;              // zip file comment
// list of meta entries in
META-INF dir
private int[] metanames;
+        private int[] metaVersions;          // list of unique versions
found in META-INF/versions/
private final boolean startsWithLoc; // true, if zip file starts
with LOCSIG (usually true)

// A Hashmap for all entries.
@@ -1424,6 +1431,8 @@ public class ZipFile implements ZipConstants,
Closeable {

// list for all meta entries
ArrayList metanamesList = null;
+            // Set of all version numbers seen in META-INF/versions/
+            Set metaVersionsSet = null;

// Iterate through the entries in the central directory
int i = 0;
@@ -1461,6 +1470,12 @@ public class ZipFile implements ZipConstants,
Closeable {
if (metanamesList == null)
metanamesList = new ArrayList<>(4);
+                    int version = getMetaVersion(cen, pos + CENHDR + 9,
nlen);
+                    if(version != -1) {
+                        if(metaVersionsSet == null)
+                            metaVersionsSet = new HashSet<>();
+                    }
}
// skip ext and comment
pos += (CENHDR + nlen + elen + clen);
@@ -1473,6 +1488,13 @@ public class ZipFile implements ZipConstants,
Closeable {
metanames[j] = metanamesList.get(j);
}
}
+            if(metaVersionsSet != null) {
+                metaVersions = new int[metaVersionsSet.size()];
+                int c = 0;
+                for (Integer version : metaVersionsSet) {
+                    metaVersions[c++] = version;
+                }
+            }
if (pos + ENDHDR != cen.length) {
}
@@ -1556,6 +1578,49 @@ public class ZipFile implements ZipConstants,
Closeable {
&& (name[off]         ) == '/';
}

+        /*
+         * If bytes represents a non-directory name beginning
+         * with "versions/", and continuing with an integer (version)
+         * followed by a '/', then return the parsed version integer.
+         * Otherwise, return -1
+         */
+        private static int getMetaVersion(byte[] name, int off, int len) {
+            int nend = off+len;
+            if(! (len > 9                        // "versions/".length()
+                    && name[off + len - 1] != '/'  // non-directory
+                    && (name[off++] | 0x20) == 'v'
+                    && (name[off++] | 0x20) == 'e'
+                    && (name[off++] | 0x20) == 'r'
+                    && (name[off++] | 0x20) == 's'
+                    && (name[off++] | 0x20) == 'i'
+                    && (name[off++] | 0x20) == 'o'
+                    && (name[off++] | 0x20) == 'n'
+                    && (name[off++] | 0x20) == 's'
+                    && (name[off++]         ) == '/')) {
+                return -1;
+            }
+            int vstart = off;
+            for(int i = vstart; i < nend; i++) {
+                final byte c = name[i];
+                if(c != '/' && (c < '0' || c > '9')) {
+                    return -1;
+                }
+                if(c == '/') {
+                    int vlen = i - vstart;
+
+                    if(vlen < 1) {
+                        return -1;
+                    }
+                    try {
+                        return Integer.parseInt(new String(name, vstart,
vlen, UTF_8.INSTANCE));
+                    } catch (NumberFormatException e) {
+                        return -1;
+                    }
+                }
+            }
+            return -1;
+        }
+
/**
* Returns the number of CEN headers in a central directory.
* Will not throw, even if the zip file is corrupt.
diff --git
a/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
b/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
index 10187e2f50..0d808b9286 100644
---
a/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
+++
b/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
@@ -35,6 +35,7 @@ import java.util.zip.ZipFile;
public interface JavaUtilZipFileAccess {
public String[] getMetaInfEntryNames(ZipFile zip);
+    public int[] getMetaInfVersions(ZipFile zip);
public JarEntry getEntry(ZipFile zip, String name, Function func);
public Enumeration entries(ZipFile zip, Function func);
public Stream stream(ZipFile zip, Function
func);

On Sun, Apr 12, 2020 at 10:50 AM Eirik Bj?rsn?s  wrote:

> I think you could tune away a significant part of that up front cost by
>> this.stream().map(ZipEntry::getName). This will avoid expanding each
>> entry into a JarEntry internally. Perhaps this gets the up-front
>> overhead down to more acceptable levels..?
>>
>
> I found JUZFA.getMetaInfEntryNames which made the up front scanning
> cost evaporate.
>
> Should be fast for other jars as well, at least when META-INF/ is sparsely
> populated.
>
> Here's an updated patch:
>
> diff --git a/src/java.base/share/classes/java/util/jar/JarFile.java
> b/src/java.base/share/classes/java/util/jar/JarFile.java
> index 1ec0f5bdae..95472604c0 100644
> --- a/src/java.base/share/classes/java/util/jar/JarFile.java
> +++ b/src/java.base/share/classes/java/util/jar/JarFile.java
> @@ -161,7 +161,7 @@ public class JarFile extends ZipFile {
>      private final Runtime.Version version;  // current version
>      private final int versionFeature;       // version.feature()
>      private boolean isMultiRelease;         // is jar multi-release?
> -
> +    private int[] versions;                 // which versions does the
> jar contain
>      // indicates if Class-Path attribute present
>      private boolean hasClassPathAttribute;
>      // true if manifest checked for special attributes
> @@ -599,12 +599,13 @@ public class JarFile extends ZipFile {
>      }
>
>      private JarEntry getVersionedEntry(String name, JarEntry je) {
> -        if (BASE_VERSION_FEATURE < versionFeature) {
> +        int[] versions = this.versions;
> +        if (BASE_VERSION_FEATURE < versionFeature && versions != null &&
> versions.length > 0) {
>              if (!name.startsWith(META_INF)) {
>                  // search for versioned entry
> -                int v = versionFeature;
> -                while (v > BASE_VERSION_FEATURE) {
> -                    JarFileEntry vje = getEntry0(META_INF_VERSIONS + v +
> "/" + name);
> +                int v = versions.length - 1;
> +                while (v >= 0) {
> +                    JarFileEntry vje = getEntry0(META_INF_VERSIONS +
> versions[v] + "/" + name);
>                      if (vje != null) {
>                          return vje.withBasename(name);
>                      }
> @@ -1016,9 +1017,18 @@ public class JarFile extends ZipFile {
>                          byte[] lbuf = new byte[512];
>                          Attributes attr = new Attributes();
> -                            new ByteArrayInputStream(b)), lbuf);
> -                        isMultiRelease = Boolean.parseBoolean(
> -                            attr.getValue(Attributes.Name.MULTI_RELEASE));
> +                                new ByteArrayInputStream(b)), lbuf);
> +                        if(Boolean.parseBoolean(
> +
>  attr.getValue(Attributes.Name.MULTI_RELEASE))) {
> +                            isMultiRelease = true;
> +                            versions =
> Stream.of(JUZFA.getMetaInfEntryNames(this))
> +                                    .mapToInt(this::parseVersion)
> +                                    .filter(v -> v != -1 && v >=
> BASE_VERSION_FEATURE && v <= versionFeature)
> +                                    .distinct()
> +                                    .sorted()
> +                                    .toArray();
> +                        }
> +
>                      }
>                  }
>              }
> @@ -1026,6 +1036,27 @@ public class JarFile extends ZipFile {
>          }
>      }
>
> +    /**
> +     * If {@code entryName} is a a versioned entry, parse and return the
> version as an integer, otherwise return -1
> +     */
> +    private int parseVersion(String entryName) {
> +        if(!entryName.startsWith(META_INF_VERSIONS)) {
> +            return -1;
> +        }
> +
> +        int separator = entryName.indexOf("/",
> META_INF_VERSIONS.length());
> +
> +        if(separator == -1) {
> +            return -1;
> +        }
> +
> +        try {
> +            return Integer.parseInt(entryName,
> META_INF_VERSIONS.length(), separator, 10);
> +        } catch (NumberFormatException e) {
> +            return -1;
> +        }
> +    }
> +
>      synchronized void ensureInitialization() {
>          try {
>              maybeInstantiateVerifier();
>
> Eirik.
>
>

From claes.redestad at oracle.com  Sun Apr 12 14:22:36 2020
Date: Sun, 12 Apr 2020 16:22:36 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

Message-ID: <327a00e7-90ee-3c00-920f-c854878071de@oracle.com>

Hi Eirik,

I think this is shaping up nicely.

If we ensure the array returned from getMetaInfVersions is already
sorted (by e.g. using a TreeMap during parse), we could remove the
stream expression. And if we check bounds in getVersionedEntry we don't
need the field in JarFile at all.

In initCEN I think you need to subtract 9 from nlen:

getMetaVersion(cen, pos + CENHDR + 9, nlen - 9)

I suspect this meant that most entries that would have been a
valid entry were filtered out, so your patch might have ended
up with an empty versions array in your tests.

And in getMetaVersion I think we can avoid creating Strings and parse
the version inline. By using 0 as the "not a version" value we can
simplify it further:

int version = 0;
for (int i = vstart; i < nend; i++) {
final byte c = name[i];
if (c == '/') {
return version;
}
if (c < '0' || c > '9') {
return 0;
}
version = version * 10 + c - '0';
// Check for overflow
if (version < 0) {
return 0;
}
}

(Maybe we need to reject leading zeros..)

I've uploaded a version here for your convenience - let me know if
you're happy with the suggestions/edits:

Thanks!

/Claes

On 2020-04-12 13:26, Eirik Bj?rsn?s wrote:
>
> Claes,
>
> Since the ZIP index is already scanned for META-INF/ names in
> ZipFile.Source.initCEN, it might make sense to move version scanning
> there. This would also allow identifying version strings at the byte
> array level.
>
> Here's a patch which implements this:
>
> diff --git a/src/java.base/share/classes/java/util/jar/JarFile.java
> b/src/java.base/share/classes/java/util/jar/JarFile.java
> index 1ec0f5bdae..988cc837f0 100644
> --- a/src/java.base/share/classes/java/util/jar/JarFile.java
> +++ b/src/java.base/share/classes/java/util/jar/JarFile.java
> @@ -49,6 +49,7 @@ import java.util.Locale;
>  ?import java.util.NoSuchElementException;
>  ?import java.util.Objects;
>  ?import java.util.function.Function;
> +import java.util.stream.IntStream;
>  ?import java.util.stream.Stream;
>  ?import java.util.zip.ZipEntry;
>  ?import java.util.zip.ZipException;
> @@ -161,7 +162,7 @@ public class JarFile extends ZipFile {
>  ? ? ?private final Runtime.Version version; ?// current version
>  ? ? ?private final int versionFeature; ? ? ? // version.feature()
>  ? ? ?private boolean isMultiRelease; ? ? ? ? // is jar multi-release?
> -
> + ? ?private int[] versions; ? ? ? ? ? ? ? ? // which versions does the
> jar contain
>  ? ? ?// indicates if Class-Path attribute present
>  ? ? ?private boolean hasClassPathAttribute;
>  ? ? ?// true if manifest checked for special attributes
> @@ -599,12 +600,13 @@ public class JarFile extends ZipFile {
>  ? ? ?}
>
>  ? ? ?private JarEntry getVersionedEntry(String name, JarEntry je) {
> - ? ? ? ?if (BASE_VERSION_FEATURE < versionFeature) {
> + ? ? ? ?int[] versions = this.versions;
> + ? ? ? ?if (BASE_VERSION_FEATURE < versionFeature && versions != null
> && versions.length > 0) {
>  ? ? ? ? ? ? ?if (!name.startsWith(META_INF)) {
>  ? ? ? ? ? ? ? ? ?// search for versioned entry
> - ? ? ? ? ? ? ? ?int v = versionFeature;
> - ? ? ? ? ? ? ? ?while (v > BASE_VERSION_FEATURE) {
> - ? ? ? ? ? ? ? ? ? ?JarFileEntry vje = getEntry0(META_INF_VERSIONS + v
> + "/" + name);
> + ? ? ? ? ? ? ? ?int v = versions.length - 1;
> + ? ? ? ? ? ? ? ?while (v >= 0) {
> + ? ? ? ? ? ? ? ? ? ?JarFileEntry vje = getEntry0(META_INF_VERSIONS +
> versions[v] + "/" + name);
>  ? ? ? ? ? ? ? ? ? ? ?if (vje != null) {
>  ? ? ? ? ? ? ? ? ? ? ? ? ?return vje.withBasename(name);
>  ? ? ? ? ? ? ? ? ? ? ?}
> @@ -1016,9 +1018,16 @@ public class JarFile extends ZipFile {
>  ? ? ? ? ? ? ? ? ? ? ? ? ?byte[] lbuf = new byte[512];
>  ? ? ? ? ? ? ? ? ? ? ? ? ?Attributes attr = new Attributes();
>  ? ? ? ? ? ? ? ? ? ? ? ? ?attr.read(new Manifest.FastInputStream(
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ?new ByteArrayInputStream(b)), lbuf);
> - ? ? ? ? ? ? ? ? ? ? ? ?isMultiRelease = Boolean.parseBoolean(
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ?attr.getValue(Attributes.Name.MULTI_RELEASE));
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?new ByteArrayInputStream(b)), lbuf);
> + ? ? ? ? ? ? ? ? ? ? ? ?if(Boolean.parseBoolean(
> +
>  ?attr.getValue(Attributes.Name.MULTI_RELEASE))) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?isMultiRelease = true;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?versions =
> IntStream.of(JUZFA.getMetaInfVersions(this))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.filter(v -> v >=
> BASE_VERSION_FEATURE && v <= versionFeature)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.sorted()
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.toArray();
> + ? ? ? ? ? ? ? ? ? ? ? ?}
> +
>  ? ? ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ?}
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
> b/src/java.base/share/classes/java/util/zip/ZipFile.java
> index 274e8788d1..25eeb57555 100644
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
> @@ -48,6 +48,7 @@ import java.util.Iterator;
>  ?import java.util.Objects;
>  ?import java.util.NoSuchElementException;
>  ?import java.util.Set;
> +import java.util.HashSet;
>  ?import java.util.Spliterator;
>  ?import java.util.Spliterators;
>  ?import java.util.WeakHashMap;
> @@ -1063,6 +1064,11 @@ public class ZipFile implements ZipConstants,
> Closeable {
>  ? ? ? ? ? ? ? ? ? ? ?return zip.getMetaInfEntryNames();
>  ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ? ? ?@Override
> + ? ? ? ? ? ? ? ?public int[] getMetaInfVersions(ZipFile zip) {
> + ? ? ? ? ? ? ? ? ? ?final int[] metaVersions = zip.res.zsrc.metaVersions;
> + ? ? ? ? ? ? ? ? ? ?return metaVersions == null ? new int[0] :
> metaVersions;
> + ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ? ? ?@Override
>  ? ? ? ? ? ? ? ? ?public JarEntry getEntry(ZipFile zip, String name,
>  ? ? ? ? ? ? ? ? ? ? ?Function func) {
>  ? ? ? ? ? ? ? ? ? ? ?return (JarEntry)zip.getEntry(name, func);
> @@ -1097,6 +1103,7 @@ public class ZipFile implements ZipConstants,
> Closeable {
>  ? ? ? ? ?private byte[] comment; ? ? ? ? ? ? ?// zip file comment
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? // list of meta entries
> in META-INF dir
>  ? ? ? ? ?private int[] metanames;
> + ? ? ? ?private int[] metaVersions; ? ? ? ? ?// list of unique versions
> found in META-INF/versions/
>  ? ? ? ? ?private final boolean startsWithLoc; // true, if zip file
> starts with LOCSIG (usually true)
>
>  ? ? ? ? ?// A Hashmap for all entries.
> @@ -1424,6 +1431,8 @@ public class ZipFile implements ZipConstants,
> Closeable {
>
>  ? ? ? ? ? ? ?// list for all meta entries
>  ? ? ? ? ? ? ?ArrayList metanamesList = null;
> + ? ? ? ? ? ?// Set of all version numbers seen in META-INF/versions/
> + ? ? ? ? ? ?Set metaVersionsSet = null;
>
>  ? ? ? ? ? ? ?// Iterate through the entries in the central directory
>  ? ? ? ? ? ? ?int i = 0;
> @@ -1461,6 +1470,12 @@ public class ZipFile implements ZipConstants,
> Closeable {
>  ? ? ? ? ? ? ? ? ? ? ?if (metanamesList == null)
>  ? ? ? ? ? ? ? ? ? ? ? ? ?metanamesList = new ArrayList<>(4);
>  ? ? ? ? ? ? ? ? ? ? ?metanamesList.add(pos);
> + ? ? ? ? ? ? ? ? ? ?int version = getMetaVersion(cen, pos + CENHDR + 9,
> nlen) > + ? ? ? ? ? ? ? ? ? ?if(version != -1) {
> + ? ? ? ? ? ? ? ? ? ? ? ?if(metaVersionsSet == null)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?metaVersionsSet = new HashSet<>();
> + ? ? ? ? ? ? ? ? ? ? ? ?metaVersionsSet.add(version);
> + ? ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ? ? ?// skip ext and comment
>  ? ? ? ? ? ? ? ? ?pos += (CENHDR + nlen + elen + clen);
> @@ -1473,6 +1488,13 @@ public class ZipFile implements ZipConstants,
> Closeable {
>  ? ? ? ? ? ? ? ? ? ? ?metanames[j] = metanamesList.get(j);
>  ? ? ? ? ? ? ? ? ?}
>  ? ? ? ? ? ? ?}
> + ? ? ? ? ? ?if(metaVersionsSet != null) {
> + ? ? ? ? ? ? ? ?metaVersions = new int[metaVersionsSet.size()];
> + ? ? ? ? ? ? ? ?int c = 0;
> + ? ? ? ? ? ? ? ?for (Integer version : metaVersionsSet) {
> + ? ? ? ? ? ? ? ? ? ?metaVersions[c++] = version;
> + ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ?}
>  ? ? ? ? ? ? ?if (pos + ENDHDR != cen.length) {
>  ? ? ? ? ? ? ?}
> @@ -1556,6 +1578,49 @@ public class ZipFile implements ZipConstants,
> Closeable {
>  ? ? ? ? ? ? ? ? ?&& (name[off] ? ? ? ? ) == '/';
>  ? ? ? ? ?}
>
> + ? ? ? ?/*
> + ? ? ? ? * If bytes represents a non-directory name beginning
> + ? ? ? ? * with "versions/", and continuing with an integer (version)
> + ? ? ? ? * followed by a '/', then return the parsed version integer.
> + ? ? ? ? * Otherwise, return -1
> + ? ? ? ? */
> + ? ? ? ?private static int getMetaVersion(byte[] name, int off, int len) {
> + ? ? ? ? ? ?int nend = off+len;
> + ? ? ? ? ? ?if(! (len > 9 ? ? ? ? ? ? ? ? ? ? ? ?// "versions/".length()
> + ? ? ? ? ? ? ? ? ? ?&& name[off + len - 1] != '/' ?// non-directory
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'v'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'e'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'r'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 's'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'i'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'o'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 'n'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] | 0x20) == 's'
> + ? ? ? ? ? ? ? ? ? ?&& (name[off++] ? ? ? ? ) == '/')) {
> + ? ? ? ? ? ? ? ?return -1;
> + ? ? ? ? ? ?}
> + ? ? ? ? ? ?int vstart = off;
> + ? ? ? ? ? ?for(int i = vstart; i < nend; i++) {
> + ? ? ? ? ? ? ? ?final byte c = name[i];
> + ? ? ? ? ? ? ? ?if(c != '/' && (c < '0' || c > '9')) {
> + ? ? ? ? ? ? ? ? ? ?return -1;
> + ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ? ? ?if(c == '/') {
> + ? ? ? ? ? ? ? ? ? ?int vlen = i - vstart;
> +
> + ? ? ? ? ? ? ? ? ? ?if(vlen < 1) {
> + ? ? ? ? ? ? ? ? ? ? ? ?return -1;
> + ? ? ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ? ? ? ? ?try {
> + ? ? ? ? ? ? ? ? ? ? ? ?return Integer.parseInt(new String(name,
> vstart, vlen, UTF_8.INSTANCE));
> + ? ? ? ? ? ? ? ? ? ?} catch (NumberFormatException e) {
> + ? ? ? ? ? ? ? ? ? ? ? ?return -1;
> + ? ? ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ? ? ?}
> + ? ? ? ? ? ?}
> + ? ? ? ? ? ?return -1;
> + ? ? ? ?}
> +
>  ? ? ? ? ?/**
>  ? ? ? ? ? * Returns the number of CEN headers in a central directory.
>  ? ? ? ? ? * Will not throw, even if the zip file is corrupt.
> diff --git
> a/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
> b/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
> index 10187e2f50..0d808b9286 100644
> ---
> a/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
> +++
> b/src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
> @@ -35,6 +35,7 @@ import java.util.zip.ZipFile;
>  ?public interface JavaUtilZipFileAccess {
>  ? ? ?public boolean startsWithLocHeader(ZipFile zip);
>  ? ? ?public String[] getMetaInfEntryNames(ZipFile zip);
> + ? ?public int[] getMetaInfVersions(ZipFile zip);
>  ? ? ?public JarEntry getEntry(ZipFile zip, String name,
> Function func);
>  ? ? ?public Enumeration entries(ZipFile zip, Function JarEntry> func);
>  ? ? ?public Stream stream(ZipFile zip, Function JarEntry> func);
>
>
>
>
> On Sun, Apr 12, 2020 at 10:50 AM Eirik Bj?rsn?s  > wrote:
>
>         I think you could tune away a significant part of that up front
>         cost by
>         this.stream().map(ZipEntry::getName). This will avoid expanding each
>         entry into a JarEntry internally. Perhaps this gets the up-front
>         overhead down to more acceptable levels..?
>
>
>     I found JUZFA.getMetaInfEntryNames which made the up front scanning
>     cost?evaporate.
>
>     Should be fast for other jars as well, at least when META-INF/ is
>     sparsely populated.
>
>     Here's an updated patch:
>
>     diff --git a/src/java.base/share/classes/java/util/jar/JarFile.java
>     b/src/java.base/share/classes/java/util/jar/JarFile.java
>     index 1ec0f5bdae..95472604c0 100644
>     --- a/src/java.base/share/classes/java/util/jar/JarFile.java
>     +++ b/src/java.base/share/classes/java/util/jar/JarFile.java
>     @@ -161,7 +161,7 @@ public class JarFile extends ZipFile {
>      ? ? ?private final Runtime.Version version; ?// current version
>      ? ? ?private final int versionFeature; ? ? ? // version.feature()
>      ? ? ?private boolean isMultiRelease; ? ? ? ? // is jar multi-release?
>     -
>     + ? ?private int[] versions; ? ? ? ? ? ? ? ? // which versions does
>     the jar contain
>      ? ? ?// indicates if Class-Path attribute present
>      ? ? ?private boolean hasClassPathAttribute;
>      ? ? ?// true if manifest checked for special attributes
>     @@ -599,12 +599,13 @@ public class JarFile extends ZipFile {
>      ? ? ?}
>
>      ? ? ?private JarEntry getVersionedEntry(String name, JarEntry je) {
>     - ? ? ? ?if (BASE_VERSION_FEATURE < versionFeature) {
>     + ? ? ? ?int[] versions = this.versions;
>     + ? ? ? ?if (BASE_VERSION_FEATURE < versionFeature && versions !=
>     null && versions.length > 0) {
>      ? ? ? ? ? ? ?if (!name.startsWith(META_INF)) {
>      ? ? ? ? ? ? ? ? ?// search for versioned entry
>     - ? ? ? ? ? ? ? ?int v = versionFeature;
>     - ? ? ? ? ? ? ? ?while (v > BASE_VERSION_FEATURE) {
>     - ? ? ? ? ? ? ? ? ? ?JarFileEntry vje = getEntry0(META_INF_VERSIONS
>     + v + "/" + name);
>     + ? ? ? ? ? ? ? ?int v = versions.length - 1;
>     + ? ? ? ? ? ? ? ?while (v >= 0) {
>     + ? ? ? ? ? ? ? ? ? ?JarFileEntry vje = getEntry0(META_INF_VERSIONS
>     + versions[v] + "/" + name);
>      ? ? ? ? ? ? ? ? ? ? ?if (vje != null) {
>      ? ? ? ? ? ? ? ? ? ? ? ? ?return vje.withBasename(name);
>      ? ? ? ? ? ? ? ? ? ? ?}
>     @@ -1016,9 +1017,18 @@ public class JarFile extends ZipFile {
>      ? ? ? ? ? ? ? ? ? ? ? ? ?byte[] lbuf = new byte[512];
>      ? ? ? ? ? ? ? ? ? ? ? ? ?Attributes attr = new Attributes();
>      ? ? ? ? ? ? ? ? ? ? ? ? ?attr.read(new Manifest.FastInputStream(
>     - ? ? ? ? ? ? ? ? ? ? ? ? ? ?new ByteArrayInputStream(b)), lbuf);
>     - ? ? ? ? ? ? ? ? ? ? ? ?isMultiRelease = Boolean.parseBoolean(
>     -
>      ?attr.getValue(Attributes.Name.MULTI_RELEASE));
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?new ByteArrayInputStream(b)), lbuf);
>     + ? ? ? ? ? ? ? ? ? ? ? ?if(Boolean.parseBoolean(
>     +
>      ?attr.getValue(Attributes.Name.MULTI_RELEASE))) {
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ?isMultiRelease = true;
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ?versions =
>     Stream.of(JUZFA.getMetaInfEntryNames(this))
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.mapToInt(this::parseVersion)
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.filter(v -> v != -1 && v >=
>     BASE_VERSION_FEATURE && v <= versionFeature)
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.distinct()
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.sorted()
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.toArray();
>     + ? ? ? ? ? ? ? ? ? ? ? ?}
>     +
>      ? ? ? ? ? ? ? ? ? ? ?}
>      ? ? ? ? ? ? ? ? ?}
>      ? ? ? ? ? ? ?}
>     @@ -1026,6 +1036,27 @@ public class JarFile extends ZipFile {
>      ? ? ? ? ?}
>      ? ? ?}
>
>     + ? ?/**
>     + ? ? * If {@code entryName} is a a versioned entry, parse and
>     return the version as an integer, otherwise return -1
>     + ? ? */
>     + ? ?private int parseVersion(String entryName) {
>     + ? ? ? ?if(!entryName.startsWith(META_INF_VERSIONS)) {
>     + ? ? ? ? ? ?return -1;
>     + ? ? ? ?}
>     +
>     + ? ? ? ?int separator = entryName.indexOf("/",
>     META_INF_VERSIONS.length());
>     +
>     + ? ? ? ?if(separator == -1) {
>     + ? ? ? ? ? ?return -1;
>     + ? ? ? ?}
>     +
>     + ? ? ? ?try {
>     + ? ? ? ? ? ?return Integer.parseInt(entryName,
>     META_INF_VERSIONS.length(), separator, 10);
>     + ? ? ? ?} catch (NumberFormatException e) {
>     + ? ? ? ? ? ?return -1;
>     + ? ? ? ?}
>     + ? ?}
>     +
>      ? ? ?synchronized void ensureInitialization() {
>      ? ? ? ? ?try {
>      ? ? ? ? ? ? ?maybeInstantiateVerifier();
>
>     Eirik.
>

From eirbjo at gmail.com  Sun Apr 12 19:06:09 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 12 Apr 2020 21:06:09 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

<327a00e7-90ee-3c00-920f-c854878071de@oracle.com>
Message-ID:

On Sun, Apr 12, 2020 at 4:18 PM Claes Redestad
wrote:

> I think this is shaping up nicely.
>
> If we ensure the array returned from getMetaInfVersions is already
> sorted (by e.g. using a TreeMap during parse), we could remove the
> stream expression. And if we check bounds in getVersionedEntry we don't
> need the field in JarFile at all.
>

Yeah, that extra field is kind of redundant. I guess my thought was that
ordering semantics of MRJ belongs in JarFile, but it's also great to reduce
duplicated state. Perhaps we could update the ZipFile.metadataVersions
field comment to say "ordered list"?

> In initCEN I think you need to subtract 9 from nlen:
>
> getMetaVersion(cen, pos + CENHDR + 9, nlen - 9)
>

Nice catch. The constant 9 feels a bit magic here, so maybe we could add a
comment saying // 9 is "META-INF/".length. (And / or extract a local
variable)

> And in getMetaVersion I think we can avoid creating Strings and parse
> the version inline. By using 0 as the "not a version" value we can
> simplify it further:
>
>              int version = 0;
>              for (int i = vstart; i < nend; i++) {
>                  final byte c = name[i];
>                  if (c == '/') {
>                      return version;
>                  }
>                  if (c < '0' || c > '9') {
>                      return 0;
>                  }
>                  version = version * 10 + c - '0';
>                  // Check for overflow
>                  if (version < 0) {
>                      return 0;
>                  }
>              }
>

This is brilliantly clever. I stopped trying to be clever at some point in
order to maintain readability, but I think this code is both readable _and_
clever.

The javadocs for getMetaVersion should be updated to specify "Otherwise,
return 0"

Eirik.

From kim.barrett at oracle.com  Mon Apr 13 08:50:02 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 13 Apr 2020 04:50:02 -0400
Subject: RFR: 8188055: (ref) Add Reference.refersTo predicate
References:
<659956F8-C0C9-4D76-95E7-0A0736A127D6@oracle.com>
Message-ID: <601F5D78-EB7E-4C43-AB48-83A113AECC20@oracle.com>

> On Apr 9, 2020, at 11:31 AM, Paul Sandoz  wrote:
>
> Reference.java
> ?
>
> 335      *
> 336      * @return   The object to which this reference refers, or
> 337      *           {@code null} if this reference object has been cleared
>
>
> 338      */
> 339     @HotSpotIntrinsicCandidate
> 340     public T get() {

Thanks.  Changed locally; waiting for other discussions to converge before posting any new webrevs.

From weijun.wang at oracle.com  Mon Apr 13 08:53:12 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 13 Apr 2020 16:53:12 +0800
References:

<98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>

<912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
<9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>

<5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID:

The additional patch looks fine to me.

Thanks,
Max

> On Apr 12, 2020, at 3:23 AM, Vipin Sharma  wrote:
>
> Hi Pavel,
>
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo  wrote:
>>
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>
>
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
>
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the `X509Certificate` to be checked
> +     * @param cert the `X509Certificate` to be checked
>      * @param prevKey the `PublicKey` that failed
>      * @param signFlag `true` if that key was trusted to sign CRLs
>      * @param stackedCerts a `Set` of `X509Certificate`s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
>
>
>>> On 8 Apr 2020, at 17:35, Vipin Sharma  wrote:
>>>
>>>
>>>
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo  wrote:
>>>>
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>
>>>> -Pavel
>>>
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>
>>>>
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman  wrote:
>>>>>
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>>
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>
>>>>> -Alan
>>>>
>>>
>>> Regards,
>>> Vipin
>>
> Regards,
> Vipin

From vicente.romero at oracle.com  Mon Apr 13 15:05:49 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 13 Apr 2020 11:05:49 -0400
Subject: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
Message-ID: <95d41c62-dba7-240b-a3ce-357568d0f6f7@oracle.com>

Hi all,

Please review this patch that updates the ASM version to appear in JDK15
(from 7.0 to 8.0). Version 8.0 is compatible with JDK14 plus it has
several experimental APIs to cover records and sealed types. We have
also updated a number of tests (mostly record oriented tests) to use the
updated APIs. Thanks to Igor Ignatyev for his help in particular for
finding the source and fixing an issue that was provoking a failure at test:

open/test/jdk/jdk/jfr/jvm/TestLogOutput.java

This is the only substantial change that makes our copy of ASM different
from the original, apart from several @SuppressWarnings that were added
for the build to pass. The patch from Igor is this:

diff -r b2ca6a37c16b
src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
---
a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
Fri Apr 10 07:04:27 2020 -0700
+++
b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
Fri Apr 10 17:14:59 2020 -0700
@@ -222,15 +222,15 @@
???? }

???? static boolean isWhitelisted(final String internalName) {
-??????? if (!internalName.startsWith("org/objectweb/asm/")) {
+??????? if (!internalName.startsWith("jdk/internal/org/objectweb/asm/")) {
???????????? return false;
???????? }
???????? String member =
"(Annotation|Class|Field|Method|Module|RecordComponent|Signature)";
???????? return internalName.contains("Test\$")
???????????????? || Pattern.matches(
-??????????????????????? "org/objectweb/asm/util/Trace" + member +
"Visitor(\\\$.*)?", internalName)
+ "jdk/internal/org/objectweb/asm/util/Trace" + member +
"Visitor(\\\$.*)?", internalName)
???????????????? || Pattern.matches(
-??????????????????????? "org/objectweb/asm/util/Check" + member +
+ "jdk/internal/org/objectweb/asm/util/Check" + member +
???? }

???? static void checkIsPreview(final InputStream classInputStream) {

And it is basically adapting our copy to the different package prefix we
use compared to the original ASM code. I have prepared two webrevs one
at [1] which has the full change and one at [2] for which I have removed
a lot of javadoc from the full webrev for reviewers that prefer less

Thanks,
Vicente

PS, thanks to Remi for fixing in a very short time a bug I found in ASM
related to the parsing of Record attributes

[1] http://cr.openjdk.java.net/~vromero/8241627/full/webrev.01/

From eirbjo at gmail.com  Mon Apr 13 15:37:50 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 13 Apr 2020 17:37:50 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

<327a00e7-90ee-3c00-920f-c854878071de@oracle.com>

Message-ID:

I noticed that in JarFile.getEntry(name) , the first call to
getEntry0(name) call is thrown away for cases where getVersionedEntry
actually finds a versioned entry.

public ZipEntry getEntry(String name) {
JarFileEntry je = getEntry0(name);
if (isMultiRelease()) {
return getVersionedEntry(name, je);
}
return je;
}

We could avoid this wasted lookup by letting getVersionedEntry perform the
default lookup instead. There are a couple of other callers
of getVersionedEntry with different fallbacks though, so not quite sure how
to deal with that. A Supplier might work?

Eirik.

On Sun, Apr 12, 2020 at 9:06 PM Eirik Bj?rsn?s  wrote:

>
>
> On Sun, Apr 12, 2020 at 4:18 PM Claes Redestad
> wrote:
>
>> I think this is shaping up nicely.
>>
>> If we ensure the array returned from getMetaInfVersions is already
>> sorted (by e.g. using a TreeMap during parse), we could remove the
>> stream expression. And if we check bounds in getVersionedEntry we don't
>> need the field in JarFile at all.
>>
>
> Yeah, that extra field is kind of redundant. I guess my thought was that
> ordering semantics of MRJ belongs in JarFile, but it's also great to reduce
> duplicated state. Perhaps we could update the ZipFile.metadataVersions
> field comment to say "ordered list"?
>
>
>> In initCEN I think you need to subtract 9 from nlen:
>>
>> getMetaVersion(cen, pos + CENHDR + 9, nlen - 9)
>>
>
> Nice catch. The constant 9 feels a bit magic here, so maybe we could add a
> comment saying // 9 is "META-INF/".length. (And / or extract a local
> variable)
>
>
>> And in getMetaVersion I think we can avoid creating Strings and parse
>> the version inline. By using 0 as the "not a version" value we can
>> simplify it further:
>>
>>              int version = 0;
>>              for (int i = vstart; i < nend; i++) {
>>                  final byte c = name[i];
>>                  if (c == '/') {
>>                      return version;
>>                  }
>>                  if (c < '0' || c > '9') {
>>                      return 0;
>>                  }
>>                  version = version * 10 + c - '0';
>>                  // Check for overflow
>>                  if (version < 0) {
>>                      return 0;
>>                  }
>>              }
>>
>
> This is brilliantly clever. I stopped trying to be clever at some point in
> order to maintain readability, but I think this code is both readable _and_
> clever.
>
> The javadocs for getMetaVersion should be updated to specify "Otherwise,
> return 0"
>
> Eirik.
>

From philipp.kunz at paratix.ch  Mon Apr 13 17:29:46 2020
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Mon, 13 Apr 2020 19:29:46 +0200
Subject: 6202130: Need to handle UTF-8 values and break up lines longer
than 72 bytes
References:
<44EE1961-6729-4F96-8885-439FED393A81@oracle.com>

<026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch>

<10485888-3ac8-c967-0131-08fe52d2694d@oracle.com>
<6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch>
<1d249f65-8086-4806-ef91-d7ecdfcf15bc@oracle.com>
Message-ID: <220837ff2ee9039fd466089e9a77d8000d9bab70.camel@paratix.ch>

Hi Naoto,
You are absolutely right to raise the question. I've also thought about
this but haven't come up so far with a compellingly elegant solution,
at least not yet.
If only String.isLatin1 was public that would come in very handy.
Character or anything else I looked at cannot tell if a string is
ascii. BreakIterator supports iterating backwards so we could start at
the potential line end but that requires a start position that is a
boundary to start with and that is not obviously possible due to the
regional indicators and probably other code points requiring stateful
processing. Same with regexes and I wouldn't know how to express groups
that could count bytes. It does not even seem to be possible to guess
any number of characters to start searching for a boundary because of
the statefulness. Even the most simple approach to detect latin1
Strings requires an encoding or a regex such as "[^\\p{ASCII}]" which
essentially is another inefficient loop. It also does not work to
encode the string into UTF-8 in a single pass because then it is not
known which grapheme boundary matches to which byte position. I also
tried to write the header names and the ": " delimiter without breaking
first but it did not seem to significantly affect performance.
UTF_8.newEncoder cannot process single surrogates, admittedly an edge
case, but required for compatibility. I added a fast path, see patch,
the best way I could think of. Did I miss a better way to tell ascii
strings from others?
What I found actually improving performance is based on the
consideration that strings are composed of primitive chars that will be
encoded into three bytes each maximum always that up to 24 characters
can be passed to writeChar72 at a time reducing the number of
writeChar72 and in turn String.getBytes invocations. The number of
characters that can be passed to writeChar72 is at most the number of
bytes remaining on the current manifest line (linePos) divided by three
but at least one. See attached patch.
Regards,Philipp

On Mon, 2020-03-30 at 14:31 -0700, naoto.sato at oracle.com wrote:
> Hi Philipp,
> Sorry for the delay.
> On 3/25/20 11:52 AM, Philipp Kunz wrote:
> > Hi Naoto,
> > See another patch attached with Locale.ROOT for the BreakIterator.
> > I will be glad to hear of any feedback.
>
> I wonder how your change affects the performance, as it will do
> String.getBytes(UTF-8) per each character. I think this can
> definitely be improved by adding some fastpath, e.g., for ASCII. The
> usage of the BreakIterator is fine, though.
> > There is another patch [1] around dealing with manifest attributes
> > during application launch. It certainly is related to 6202130 but
> > feels like a distinct set of changes with a slightly different
> > concern. Any opinion as how to proceed with that one?
>
> I am not quite sure which patch you are referring to, but I agree
> that creating an issue would not hurt.
> Naoto
> > Regards,Philipp
> >
> >
> > [1]
> > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html
> >
> >
> > On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote:
> > > Hi Philipp,
> > > Right, Locale.ROOT is more appropriate here by definition, though
> > > theimplementation is the same.
> > > Naoto
> > > On 3/21/20 5:19 AM, Philipp Kunz wrote:
> > > > Hi Naoto and everyone,
> > > > There are almost as many occurrences of Locale.ROOT as
> > > > Locale.US whichmade me wonder which one is more appropriately
> > > > locale-independent andwhich is probably another topic and not
> > > > actually relevant here
> > > > becauseBreakIterator.getCharacterInstance is locale-agnostic as
> > > > far as I can tell.
> > > > See attached patch with another attempt to fix bug 6202130.
> > > > Regards,Philipp
> > > >
> > > > On Tue, 2020-03-10 at 10:45 -0700,naoto.sato at oracle.com
> > > >    wrote:
> > > > > Hi Philipp,
> > > > > ..., so using BreakIterator (withLocale.US) is more preferred
> > > > > solution to me.
> > > > > Naoto

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20200413-bug6202130-manifestutf8.patch
Type: text/x-patch
Size: 60361 bytes
Desc: not available
URL:

From eirbjo at gmail.com  Mon Apr 13 19:26:46 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 13 Apr 2020 21:26:46 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
Message-ID:

Hi,

While working on improvements to JarFile.getVersionedEntry, it occurred to
me that the missing lookups we are removing there may be just one example
of a more general issue.

To get a better understanding of how ZipFile.getEntry is used, I added some
PerfCounters for the number of hits and misses in calls to
ZipFile.Source.getEntryPos() and the elapsed run times for these hits and
misses.

To test this I used Spring PetClinic. I only care about startup time here,
since that's when most of the Zip lookups happens.

Here's what I found:

Hits 10776, misses: 744642
=> 1.4 percent of lookups are hits

Hits runtime: 7995508 ns, miss runtime: 328360900 ns
=> 2.4 percent of run time is spent on hits.

The startup time reported by Spring Petclinic was 6395 ms. 5 percent of
this startup time was spent on missed getEntry lookups.

If we can improve the performance of lookup misses, I think there is a good
potential for overall performance wins.

One idea I had about how this could be done was to use Bloom filters. Bloom
filters provide a fast, space-efficient, probabilistic data structure which
may be used to determine that an element is definitely not a member of a
set.

I made a sloppy Bloom filter implementation and updated
ZipFile.Source.getEntryPos to check this filter first and return -1 if the
name is definitely not in the jar.

This gave the following results for Spring Petclinic startup:

Hits run time: 10964825 ns, miss runtime: 233868876 ns

We see that while hits are now 1.4x slower, the total time spent on lookups
is only 73 percent compared to that of the baseline.

This translates to a Petclinic startup improvement of 91 ms or 1.4 percent

I expect that this can be improved further with a more clever use of hash
functions. Specifically it would be great to skip earlier in case of a
miss, before the String to byte[] encoding happens. Also, I haven't
analysed the false positive rate in the bloom filter, so that's probably
open for some tuning.

I also expect lookup misses to be even more common on applications with
longer class paths and more complex class loader delegation.

Cheers,
Eirik.

From eirbjo at gmail.com  Mon Apr 13 20:57:02 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 13 Apr 2020 22:57:02 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:
Message-ID:

On Mon, Apr 13, 2020 at 9:26 PM Eirik Bj?rsn?s  wrote:

This translates to a Petclinic startup improvement of 91 ms or 1.4 percent
>
> I expect that this can be improved further with a more clever use of hash
> functions. Specifically it would be great to skip earlier in case of a
> miss, before the String to byte[] encoding happens.
>

By using the String name hash before encoding it to bytes, savings
increased to 270 ms, which represents a 4.6 percent performance improvement
on Spring Petclinic startup.

Eirik.

From rafael.wth at gmail.com  Tue Apr 14 08:01:23 2020
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 14 Apr 2020 10:01:23 +0200
Subject: Reasoning behind exposing getGenericSignature in RecordComponent
Message-ID:

Hello,
I was wondering what the motivation was behind exposing the
getGenericSignature method in RecordComponent. This method also exists in
the Method and Field classes but is private there. If there is an argument
to expose the method in RecordComponent, wouldn't it make sense to also
expose it there? I am a bit surprised to find the method public in the
first place, few people have a relation to class format concepts at runtime.
Thanks for the clarification.
Best regards, Rafael

From Alan.Bateman at oracle.com  Tue Apr 14 08:14:53 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Apr 2020 09:14:53 +0100
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

<327a00e7-90ee-3c00-920f-c854878071de@oracle.com>

Message-ID: <5c199960-5f54-d978-1615-f699d88a4536@oracle.com>

Would it be possible to send an updated webrev with the patch that is
proposed for jdk/jdk? One thing that I'm concerned about is that
META-INF/* is a JAR file concepts and I'd prefer not build up further
shared secrets that operate on ZipFile (should be consistent JarFile and
JarEntry when dealing with JAR files).

-Alan

On 12/04/2020 20:06, Eirik Bj?rsn?s wrote:
> On Sun, Apr 12, 2020 at 4:18 PM Claes Redestad
> wrote:
>
>> I think this is shaping up nicely.
>>
>> If we ensure the array returned from getMetaInfVersions is already
>> sorted (by e.g. using a TreeMap during parse), we could remove the
>> stream expression. And if we check bounds in getVersionedEntry we don't
>> need the field in JarFile at all.
>>
> Yeah, that extra field is kind of redundant. I guess my thought was that
> ordering semantics of MRJ belongs in JarFile, but it's also great to reduce
> duplicated state. Perhaps we could update the ZipFile.metadataVersions
> field comment to say "ordered list"?
>
>
>> In initCEN I think you need to subtract 9 from nlen:
>>
>> getMetaVersion(cen, pos + CENHDR + 9, nlen - 9)
>>
> Nice catch. The constant 9 feels a bit magic here, so maybe we could add a
> comment saying // 9 is "META-INF/".length. (And / or extract a local
> variable)
>
>
>> And in getMetaVersion I think we can avoid creating Strings and parse
>> the version inline. By using 0 as the "not a version" value we can
>> simplify it further:
>>
>>               int version = 0;
>>               for (int i = vstart; i < nend; i++) {
>>                   final byte c = name[i];
>>                   if (c == '/') {
>>                       return version;
>>                   }
>>                   if (c < '0' || c > '9') {
>>                       return 0;
>>                   }
>>                   version = version * 10 + c - '0';
>>                   // Check for overflow
>>                   if (version < 0) {
>>                       return 0;
>>                   }
>>               }
>>
> This is brilliantly clever. I stopped trying to be clever at some point in
> order to maintain readability, but I think this code is both readable _and_
> clever.
>
> The javadocs for getMetaVersion should be updated to specify "Otherwise,
> return 0"
>
> Eirik.

From eirbjo at gmail.com  Tue Apr 14 08:59:07 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 14 Apr 2020 10:59:07 +0200
Subject: JarFile.getVersionedEntry scalability with new release cadence
References:
<5C1C9A72-6779-42E8-922B-F47E7C8F0ACB@oracle.com>

<327a00e7-90ee-3c00-920f-c854878071de@oracle.com>

<5c199960-5f54-d978-1615-f699d88a4536@oracle.com>
Message-ID:

On Tue, Apr 14, 2020 at 10:15 AM Alan Bateman
wrote:

Would it be possible to send an updated webrev with the patch that is
> proposed for jdk/jdk?

My understanding is that Claes may initiate a formal review once my OCA is
processed and he's done some testing.

> One thing that I'm concerned about is that
> META-INF/* is a JAR file concepts and I'd prefer not build up further
> shared secrets that operate on ZipFile (should be consistent JarFile and
> JarEntry when dealing with JAR files).
>

True. META-INF/ semantically belongs in JarFile. The reasons for moving the
parsing logic to ZipFile.Source were:

1: Scanning of META-INF/ entries already happens there and scanning
META-INF/versions/ is tightly related to this (it's a sub-problem).
2: Acceptable performance requires that we keep parsing on the byte[]
level, without String conversions. The CEN isn't directly available in
binary from from JarFile.

Eirik.

From eirbjo at gmail.com  Tue Apr 14 10:58:20 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 14 Apr 2020 12:58:20 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:

Message-ID:

Here's a patch implementing the Bloom filter idea for JarFile.getEntry().

The patch yields a 63% time saving in ZipFile.getEntry() calls during
Spring Petclinic startup, reducing total application startup time by ~5%.
(Hits are 7% slower, misses 65% faster)

The current patch decodes the name to a String and as a temporary hack
assumes UTF-8. This needs to be improved.

Would be great if there was a way to calculate a String.hashCode()
equivalent looking at a byte array and its encoding without actually
decoding it.

diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
b/src/java.base/share/classes/java/util/zip/ZipFile.java
index 274e8788d1..754b1fc868 100644
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
@@ -40,6 +40,7 @@ import java.nio.file.Files;
import java.util.ArrayDeque;
import java.util.ArrayList;
import java.util.Arrays;
+import java.util.BitSet;
import java.util.Collections;
import java.util.Deque;
import java.util.Enumeration;
@@ -336,6 +337,9 @@ public class ZipFile implements ZipConstants, Closeable
{
Objects.requireNonNull(name, "name");
synchronized (this) {
ensureOpen();
+            if(!this.res.zsrc.bloomFilter.mightContain(name.hashCode())) {
+                return null;
+            }
byte[] bname = zc.getBytes(name);
int pos = res.zsrc.getEntryPos(bname, true);
if (pos != -1) {
@@ -1118,6 +1122,8 @@ public class ZipFile implements ZipConstants,
Closeable {
// referred by their index of their positions in the {@code
entries}.
//
private int[] entries;                  // array of hashed cen
entry
+        private BloomFilter bloomFilter;
+
private int addEntry(int index, int hash, int next, int pos) {
entries[index++] = hash;
entries[index++] = next;
@@ -1422,6 +1428,7 @@ public class ZipFile implements ZipConstants,
Closeable {
int hash = 0;
int next = -1;

+            bloomFilter = BloomFilter.create(total, 0.01);
// list for all meta entries
ArrayList metanamesList = null;

@@ -1430,6 +1437,10 @@ public class ZipFile implements ZipConstants,
Closeable {
int hsh = 0;
int pos = 0;
int limit = cen.length - ENDHDR;
+
+            // TODO: Use actual charset or get hash without decoding
+            final ZipCoder zc = ZipCoder.get(UTF_8.INSTANCE);
+
while (pos + CENHDR <= limit) {
if (i >= total) {
// This will only happen if the zip file has an
incorrect
@@ -1452,6 +1463,8 @@ public class ZipFile implements ZipConstants,
Closeable {
// Record the CEN offset and the name hash in our hash
cell.
hash = hashN(cen, pos + CENHDR, nlen);
+                // TODO: Get String hash without decoding name?
hsh = (hash & 0x7fffffff) % tablelen;
next = table[hsh];
table[hsh] = idx;
@@ -1478,6 +1491,16 @@ public class ZipFile implements ZipConstants,
Closeable {
}
}

+        // Used to produce the String.hashCode() of the entry name
+        private String getEntryName(byte[] cen, int pos, ZipCoder zc) {
+            int nlen = CENNAM(cen, pos);
+            if (!zc.isUTF8() && (CENFLG(cen, pos) & USE_UTF8) != 0) {
+                return zc.toStringUTF8(cen, pos + CENHDR, nlen);
+            } else {
+                return zc.toString(cen, pos + CENHDR, nlen);
+            }
+        }
+
private static void zerror(String msg) throws ZipException {
throw new ZipException(msg);
}
@@ -1572,4 +1595,53 @@ public class ZipFile implements ZipConstants,
Closeable {
return count;
}
}
+
+    /**
+     * See "Less Hashing, Same Performance: Building a Better Bloom Filter"
+     */
+    private static class BloomFilter {
+
+        private final BitSet bits;
+        private final int numBits;
+        private final int numHashFunctions;
+
+        private BloomFilter(int numBits, int numHashFunctions) {
+            this.bits = new BitSet(numBits);
+            this.numBits = numBits;
+            this.numHashFunctions = numHashFunctions;
+        }
+
+        static BloomFilter create(int n, double p) {
+            // See
https://en.wikipedia.org/wiki/Bloom_filter#Probability_of_false_positives
+            int numBits = (int) (-n * Math.log(Math.max(p,
Double.MIN_VALUE)) / (Math.log(2) * Math.log(2)));
+            int numHashFunctions =  Math.max(1, (int) Math.round((double)
numBits / n * Math.log(2)));
+            return new BloomFilter(numBits, numHashFunctions);
+        }
+
+            for (int i = 1; i <= numHashFunctions; i++) {
+                int hash = inputHash + i * inputHash;
+
+                if (hash < 0)
+                    hash = ~hash;
+
+                bits.set(hash % numBits);
+            }
+        }
+
+        boolean mightContain(int inputHash) {
+
+            for (int i = 1; i <= numHashFunctions; i++) {
+                int hash = inputHash + i * inputHash;
+
+                if (hash < 0)
+                    hash = ~hash;
+
+                if(!bits.get(hash % numBits)) {
+                    return false;
+                }
+            }
+            return true;
+        }
+    }
}

On Mon, Apr 13, 2020 at 10:57 PM Eirik Bj?rsn?s  wrote:

> On Mon, Apr 13, 2020 at 9:26 PM Eirik Bj?rsn?s  wrote:
>
> This translates to a Petclinic startup improvement of 91 ms or 1.4 percent
>>
>> I expect that this can be improved further with a more clever use of hash
>> functions. Specifically it would be great to skip earlier in case of a
>> miss, before the String to byte[] encoding happens.
>>
>
> By using the String name hash before encoding it to bytes, savings
> increased to 270 ms, which represents a 4.6 percent performance improvement
> on Spring Petclinic startup.
>
> Eirik.
>

From claes.redestad at oracle.com  Tue Apr 14 11:26:31 2020
Date: Tue, 14 Apr 2020 13:26:31 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:

Message-ID: <6458461c-e44c-946a-9fe0-a517b7146450@oracle.com>

Hi Eirik,

interesting idea and results.

I wonder if the overhead you remove here is mainly avoiding the need to
call byte[] bname = zc.getBytes(name); during lookup.

If we refactored ZipCoder to have a zc.getHash(name) method and
getEntryPos to decode to a byte[] only lazily, we ought to be able to
get most of the speed-up for the miss case, and none (or very little)
added cost on hits. And no added footprint for a bloom filter.

int pos = res.zsrc.getEntryPos(zc, name, true);
...
getEntryPos(ZipCoder zc, String name, boolean addSlash) {
if (total == 0) {
return -1;
}
int hash = zc.getHash(name);
int idx = table[(hsh & 0x7fffffff) % tablelen];
byte[] bname = null;
...
while (idx != ZIP_ENDCHAIN) {
if (getEntryHash(idx) == hsh) {
if (bname == null) {
bname = zc.getBytes(name);
}
if (bname.length == ...

What do you think?

Thanks!

/Claes

On 2020-04-14 12:58, Eirik Bj?rsn?s wrote:
> Here's a patch implementing the Bloom filter idea for JarFile.getEntry().
>
> The patch yields a 63% time saving in ZipFile.getEntry() calls during
> Spring Petclinic startup, reducing total application startup time by ~5%.
> (Hits are 7% slower, misses 65% faster)
>
> The current patch decodes the name to a String and as a temporary hack
> assumes UTF-8. This needs to be improved.
>
> Would be great if there was a way to calculate a String.hashCode()
> equivalent looking at a byte array and its encoding without actually
> decoding it.
>
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
> b/src/java.base/share/classes/java/util/zip/ZipFile.java
> index 274e8788d1..754b1fc868 100644
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
> @@ -40,6 +40,7 @@ import java.nio.file.Files;
>   import java.util.ArrayDeque;
>   import java.util.ArrayList;
>   import java.util.Arrays;
> +import java.util.BitSet;
>   import java.util.Collections;
>   import java.util.Deque;
>   import java.util.Enumeration;
> @@ -336,6 +337,9 @@ public class ZipFile implements ZipConstants, Closeable
> {
>           Objects.requireNonNull(name, "name");
>           synchronized (this) {
>               ensureOpen();
> +            if(!this.res.zsrc.bloomFilter.mightContain(name.hashCode())) {
> +                return null;
> +            }
>               byte[] bname = zc.getBytes(name);
>               int pos = res.zsrc.getEntryPos(bname, true);
>               if (pos != -1) {
> @@ -1118,6 +1122,8 @@ public class ZipFile implements ZipConstants,
> Closeable {
>           // referred by their index of their positions in the {@code
> entries}.
>           //
>           private int[] entries;                  // array of hashed cen
> entry
> +        private BloomFilter bloomFilter;
> +
>           private int addEntry(int index, int hash, int next, int pos) {
>               entries[index++] = hash;
>               entries[index++] = next;
> @@ -1422,6 +1428,7 @@ public class ZipFile implements ZipConstants,
> Closeable {
>               int hash = 0;
>               int next = -1;
>
> +            bloomFilter = BloomFilter.create(total, 0.01);
>               // list for all meta entries
>               ArrayList metanamesList = null;
>
> @@ -1430,6 +1437,10 @@ public class ZipFile implements ZipConstants,
> Closeable {
>               int hsh = 0;
>               int pos = 0;
>               int limit = cen.length - ENDHDR;
> +
> +            // TODO: Use actual charset or get hash without decoding
> +            final ZipCoder zc = ZipCoder.get(UTF_8.INSTANCE);
> +
>               while (pos + CENHDR <= limit) {
>                   if (i >= total) {
>                       // This will only happen if the zip file has an
> incorrect
> @@ -1452,6 +1463,8 @@ public class ZipFile implements ZipConstants,
> Closeable {
>                   // Record the CEN offset and the name hash in our hash
> cell.
>                   hash = hashN(cen, pos + CENHDR, nlen);
> +                // TODO: Get String hash without decoding name?
>                   hsh = (hash & 0x7fffffff) % tablelen;
>                   next = table[hsh];
>                   table[hsh] = idx;
> @@ -1478,6 +1491,16 @@ public class ZipFile implements ZipConstants,
> Closeable {
>               }
>           }
>
> +        // Used to produce the String.hashCode() of the entry name
> +        private String getEntryName(byte[] cen, int pos, ZipCoder zc) {
> +            int nlen = CENNAM(cen, pos);
> +            if (!zc.isUTF8() && (CENFLG(cen, pos) & USE_UTF8) != 0) {
> +                return zc.toStringUTF8(cen, pos + CENHDR, nlen);
> +            } else {
> +                return zc.toString(cen, pos + CENHDR, nlen);
> +            }
> +        }
> +
>           private static void zerror(String msg) throws ZipException {
>               throw new ZipException(msg);
>           }
> @@ -1572,4 +1595,53 @@ public class ZipFile implements ZipConstants,
> Closeable {
>               return count;
>           }
>       }
> +
> +    /**
> +     * See "Less Hashing, Same Performance: Building a Better Bloom Filter"
> +     */
> +    private static class BloomFilter {
> +
> +        private final BitSet bits;
> +        private final int numBits;
> +        private final int numHashFunctions;
> +
> +        private BloomFilter(int numBits, int numHashFunctions) {
> +            this.bits = new BitSet(numBits);
> +            this.numBits = numBits;
> +            this.numHashFunctions = numHashFunctions;
> +        }
> +
> +        static BloomFilter create(int n, double p) {
> +            // See
> https://en.wikipedia.org/wiki/Bloom_filter#Probability_of_false_positives
> +            int numBits = (int) (-n * Math.log(Math.max(p,
> Double.MIN_VALUE)) / (Math.log(2) * Math.log(2)));
> +            int numHashFunctions =  Math.max(1, (int) Math.round((double)
> numBits / n * Math.log(2)));
> +            return new BloomFilter(numBits, numHashFunctions);
> +        }
> +
> +        void add(int inputHash) {
> +            for (int i = 1; i <= numHashFunctions; i++) {
> +                int hash = inputHash + i * inputHash;
> +
> +                if (hash < 0)
> +                    hash = ~hash;
> +
> +                bits.set(hash % numBits);
> +            }
> +        }
> +
> +        boolean mightContain(int inputHash) {
> +
> +            for (int i = 1; i <= numHashFunctions; i++) {
> +                int hash = inputHash + i * inputHash;
> +
> +                if (hash < 0)
> +                    hash = ~hash;
> +
> +                if(!bits.get(hash % numBits)) {
> +                    return false;
> +                }
> +            }
> +            return true;
> +        }
> +    }
>   }
>
>
>
> On Mon, Apr 13, 2020 at 10:57 PM Eirik Bj?rsn?s  wrote:
>
>> On Mon, Apr 13, 2020 at 9:26 PM Eirik Bj?rsn?s  wrote:
>>
>> This translates to a Petclinic startup improvement of 91 ms or 1.4 percent
>>>
>>> I expect that this can be improved further with a more clever use of hash
>>> functions. Specifically it would be great to skip earlier in case of a
>>> miss, before the String to byte[] encoding happens.
>>>
>>
>> By using the String name hash before encoding it to bytes, savings
>> increased to 270 ms, which represents a 4.6 percent performance improvement
>> on Spring Petclinic startup.
>>
>> Eirik.
>>

From eirbjo at gmail.com  Tue Apr 14 12:06:21 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 14 Apr 2020 14:06:21 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:

<6458461c-e44c-946a-9fe0-a517b7146450@oracle.com>
Message-ID:

>
> I wonder if the overhead you remove here is mainly avoiding the need to
> call byte[] bname = zc.getBytes(name); during lookup.
>

If I got my numbers right, 67% of the saved time was due to less executions
of this method.

The remaining 33% should be explained by the bloom filter providing a
faster negative lookup than the hash table.

> If we refactored ZipCoder to have a zc.getHash(name) method and
> getEntryPos to decode to a byte[] only lazily, we ought to be able to
> get most of the speed-up for the miss case, and none (or very little)
> added cost on hits. And no added footprint for a bloom filter.
>
> What do you think?
>

Looks like a nice way to get 67% of the savings without the extra footprint
(which is ~10 bits per entry IIRC).

The read and write sides would need to agree on their hash functions
though. The read side is looking on strings and the write side on byte
arrays. So you have the same problem I have in my current patch. How would
you calculate the hash value?

Eirik.

From claes.redestad at oracle.com  Tue Apr 14 12:30:36 2020
Date: Tue, 14 Apr 2020 14:30:36 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:

<6458461c-e44c-946a-9fe0-a517b7146450@oracle.com>

Message-ID: <7883dcaa-7dbf-2284-7ff3-d09e3759fef1@oracle.com>

On 2020-04-14 14:06, Eirik Bj?rsn?s wrote:
>     I wonder if the overhead you remove here is mainly avoiding the need to
>     call byte[] bname = zc.getBytes(name); during lookup.
>
>
> If I got my numbers right, 67% of the saved time was?due to less
> executions of this method.
>
> The remaining 33% should be explained by the bloom filter providing a
> faster negative lookup than the hash table.
>
>     If we refactored ZipCoder to have a zc.getHash(name) method and
>     getEntryPos to decode to a byte[] only lazily, we ought to be able to
>     get most of the speed-up for the miss case, and none (or very little)
>     added cost on hits. And no added footprint for a bloom filter.
>
>     What do you think?
>
>
> Looks like a nice way to get 67% of the savings without the extra
> footprint (which is ~10 bits per entry IIRC).

Right, not sure the extra footprint (and complexity) would be worth that

>
> The read and write sides would need to agree on their hash functions
> though. The read side is looking on strings and the write side on byte
> arrays. So you have the same problem I have in my current patch. How
> would you calculate the hash value?

Yeah, the String encoder APIs doesn't lend themselves well to do hash
calculations over a String without taking the overhead of allocating
the byte[] (and ByteBuffer, and ...), and we obviously need to ensure
we use effectively the same hash function on both ends.

One trick is to exploit that the standard UTF-8 encoding is ASCII
compatible (all chars 0-127 will encode unchanged), so we can
speculatively assume the String is ASCII and calculate the hash code
directly using a charAt loop - and return -1 to mark that the String
wasn't ASCII and needs to be encoded. The false positive case when hash
actually is -1 will be handled gracefully:

Almost all entries in common libraries are likely to have names which
are ASCII-compat, so this should enable the speed-up for most cases with
little complexity.

/Claes

>
> Eirik.

From daniel.fuchs at oracle.com  Tue Apr 14 12:29:07 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2020 13:29:07 +0100
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>
Message-ID:

Hi,

On 11/04/2020 00:53, David Holmes wrote:
> Update:
>> It's a holiday weekend so I can't dig into this right now but we tried
>> using a high-precision clock source for systemUTC() in the past but it
>> didn't work because systemUTC() and currentTimeMillis() have to use
>> the same time base, and currentTimeMillis() has to use gettimeofday().
>> I thought this cross-dependency was documented somewhere but can't
>> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
>> actually have the same time characteristics wrt. wall-clock time then
>> changing both as suggested may indeed work.

Just to emphasize David's comment: System::currentTimeMillis() and
Clock::systemUTC() should use the same time source: if they don't - then
some tests will fail, and because it can be tricky to assert things
in tests, they might (and probably will) fail only intermittently.

I'm probably the culprit here, I added those tests when I upgraded
Clock::systemUTC() to report sub millisecond granularity [1] - as was
available in the underlying clock that System::currentTimeMillis()

However, I think I would be disturbed if System::currentTimeMillis()
and Clock::systemUTC() were using different clocks and could
report a different notion of time (by drifting away from each other).

best regards,

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

From eirbjo at gmail.com  Tue Apr 14 13:19:33 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 14 Apr 2020 15:19:33 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:

<6458461c-e44c-946a-9fe0-a517b7146450@oracle.com>

Message-ID:

On Tue, Apr 14, 2020 at 2:06 PM Eirik Bj?rsn?s  wrote:

> The remaining 33% should be explained by the bloom filter providing a
> faster negative lookup than the hash table.
>

This made me wonder if a hash map is the optimal data structure for this
kind of read-only lookups. There's good amount of pointer chasing and
scanning going on and it's probably not very cache friendly.

My intuition is that an array sorted by lookup key plus a binary search for
lookups could be faster.

Eirik.

From jorn.vernee at oracle.com  Tue Apr 14 16:18:58 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 14 Apr 2020 18:18:58 +0200
Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and
Short implement Constable
References:
<2e10bbbe-1faf-f4a8-d04b-88151a4e1122@oracle.com>

Hi David,

Thanks for the heads up! A CSR for this patch was created here:
https://bugs.openjdk.java.net/browse/JDK-8241667

It was moved to 'provisional' today, but still requires one or more
engineer reviews.

Could someone here review the CSR?

Thanks,
Jorn

On 18/03/2020 22:59, David Holmes wrote:
> Hi Jorn,
>
> This needs a CSR request before it can be pushed.
>
> Thanks,
> David
>
> On 19/03/2020 12:08 am, Jorn Vernee wrote:
>> Hi,
>>
>> Byte, and Short implement Constable?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
>> Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/
>>
>> Having the other box types implement Constable makes them easier to
>> use with APIs that accept any Constable. Though I'm mostly
>> interesting in boolean, for which I'm currently falling back to
>> "true" & "false" strings, but the downside is that this also requires
>> parsing the string again and having to deal with random other strings.
>>
>> This patch also adds the ConstantBootstraps::convert method that is
>> used to facilitate the conversion from int to (short|char|byte). This
>> currently takes a source type explicitly. In practice, it seems that
>> Object can always be used as a source type for the same behavior, but
>> explicitly specifying source and destination types seems more robust
>> to me in case this behavior ever changes, or we want to expand on the
>> supported kinds of conversion. (for instance it is currently not
>> possible to convert from an int to a Long directly, or from Short to
>> Integer, but maybe those cases could be supported in the future as
>> well).
>>
>> Testing: tier1-3 & downstream testing for my particular use case
>>
>> Thanks,
>> Jorn
>>

From philipp.kunz at paratix.ch  Tue Apr 14 16:26:54 2020
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Tue, 14 Apr 2020 18:26:54 +0200
Subject: RFR: 8241055: Regex Grapheme Matcher Performance Depends too
much on Total Input Sequence Size
References: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch>

Message-ID:

Hi Naoto,

I agree, see attached patch.

Regards,
Philipp

On Thu, 2020-03-26 at 14:14 -0700, naoto.sato at oracle.com wrote:
> Hi Philipp,
>
> I looked at the patch, and it looks good to me. As to the test case,
> since it is measuring the performance, I would make it in a JMH test.
> Maybe you would want to put it similar to
> open/test/micro/org/openjdk/bench/java/util/regex/PatternBench.java
>
> Minor suggestion: I would rather rename "getGraphemeType()" to just
> "getType()", as it is simply retrieving the character type.
>
> Naoto
>
> On 3/21/20 7:58 AM, Philipp Kunz wrote:
> > Hi,
> >
> > Any opinions on the attached patch or someone tempted to sponsor it?
> >
> > Regards,
> > Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20200414-bug8241055-graphemecomplexity.patch
Type: text/x-patch
Size: 14816 bytes
Desc: not available
URL:

From kralj.mark at gmail.com  Tue Apr 14 17:04:16 2020
From: kralj.mark at gmail.com (Mark Kralj-Taylor)
Date: Tue, 14 Apr 2020 18:04:16 +0100
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

Message-ID:

Daniel,
Yes System.currentTimeMillis() and Clock.systemUTC() must be
consistent, so should use the same OS time source (as shown by ).

The patch to os_linux.cpp ensures this by calling the same Linux API:
clock_gettime(CLOCK_REALTIME) for both, from:
- os::javaTimeMillis() that backs System.currentTimeMillis()
- os::javaTimeSystemUTC() that backs Clock.systemUTC()

Looking at Linux / glibc source I think that gettimeofday() and
clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource.
i.e. that given by: cat
/sys/devices/system/clocksource/clocksource0/current_clocksource

Mark

On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs  wrote:
>
> Hi,
>
> On 11/04/2020 00:53, David Holmes wrote:
> > Update:
> >> It's a holiday weekend so I can't dig into this right now but we tried
> >> using a high-precision clock source for systemUTC() in the past but it
> >> didn't work because systemUTC() and currentTimeMillis() have to use
> >> the same time base, and currentTimeMillis() has to use gettimeofday().
> >> I thought this cross-dependency was documented somewhere but can't
> >> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
> >> actually have the same time characteristics wrt. wall-clock time then
> >> changing both as suggested may indeed work.
>
> Just to emphasize David's comment: System::currentTimeMillis() and
> Clock::systemUTC() should use the same time source: if they don't - then
> some tests will fail, and because it can be tricky to assert things
> in tests, they might (and probably will) fail only intermittently.
>
> I'm probably the culprit here, I added those tests when I upgraded
> Clock::systemUTC() to report sub millisecond granularity [1] - as was
> available in the underlying clock that System::currentTimeMillis()
>
> However, I think I would be disturbed if System::currentTimeMillis()
> and Clock::systemUTC() were using different clocks and could
> report a different notion of time (by drifting away from each other).
>
> best regards,
>
> -- daniel
> [1] https://bugs.openjdk.java.net/browse/JDK-8068730

From fw at deneb.enyo.de  Tue Apr 14 17:37:00 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 14 Apr 2020 19:37:00 +0200
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API,
so Clock.systemUTC() can give nanosecond precision UTC
(Mark Kralj-Taylor's message of "Tue, 14 Apr 2020 18:09:48 +0100")
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

Message-ID: <87sgh6klz7.fsf@mid.deneb.enyo.de>

* Mark Kralj-Taylor:

> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
> should be supported if the clock_gettime() API exists. But other clock
> sources are not mandatory.

Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
gettimeofday, yes.

clock_gettime was already in Linux 2.12 (and possibly quite a bit
earlier, I did not check), so that is not likely to be a limitation.

The present code already uses dlopen, but I think it could try a
little bit harder (try resolving clock_gettime first, and then load
librt, and try again).  For distribution builds that do not need to be
compatible with glibc versions before 2.17, directly calling
clock_gettime would also be an option. (clock_gettime moved to
libc.so.6 in glibc 2.17, but a lot of software keeps linking against
librt for the definition of clock_gettime, something that we are
finally tackling on the glibc side.)

Making a direct system call instead is a bit tricky because it's
absolutely required to use the vDSO if possible, for performance
reasons.  But it's possible to obtain the address of the vDSO function
using dlvsym, so that might be an option as well.

From paul.sandoz at oracle.com  Tue Apr 14 18:05:57 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Apr 2020 11:05:57 -0700
Subject: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
References: <95d41c62-dba7-240b-a3ce-357568d0f6f7@oracle.com>
Message-ID:

Hi Vicente,

Looks ok from the changes required to integrate into the JDK.

Maybe the @SuppressWarnings warning annotations could be upstreamed?

Paul.

> On Apr 13, 2020, at 8:05 AM, Vicente Romero  wrote:
>
> Hi all,
>
> Please review this patch that updates the ASM version to appear in JDK15 (from 7.0 to 8.0). Version 8.0 is compatible with JDK14 plus it has several experimental APIs to cover records and sealed types. We have also updated a number of tests (mostly record oriented tests) to use the updated APIs. Thanks to Igor Ignatyev for his help in particular for finding the source and fixing an issue that was provoking a failure at test:
>
> open/test/jdk/jdk/jfr/jvm/TestLogOutput.java
>
> This is the only substantial change that makes our copy of ASM different from the original, apart from several @SuppressWarnings that were added for the build to pass. The patch from Igor is this:
>
> diff -r b2ca6a37c16b src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
> --- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 07:04:27 2020 -0700
> +++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 17:14:59 2020 -0700
> @@ -222,15 +222,15 @@
>      }
>
>      static boolean isWhitelisted(final String internalName) {
> -        if (!internalName.startsWith("org/objectweb/asm/")) {
> +        if (!internalName.startsWith("jdk/internal/org/objectweb/asm/")) {
>              return false;
>          }
>          String member = "(Annotation|Class|Field|Method|Module|RecordComponent|Signature)";
>          return internalName.contains("Test\$")
>                  || Pattern.matches(
> -                        "org/objectweb/asm/util/Trace" + member + "Visitor(\\\$.*)?", internalName)
> + "jdk/internal/org/objectweb/asm/util/Trace" + member + "Visitor(\\\$.*)?", internalName)
>                  || Pattern.matches(
> -                        "org/objectweb/asm/util/Check" + member + "Adapter(\\\$.*)?", internalName);
> + "jdk/internal/org/objectweb/asm/util/Check" + member + "Adapter(\\\$.*)?", internalName);
>      }
>
>      static void checkIsPreview(final InputStream classInputStream) {
>
>
> And it is basically adapting our copy to the different package prefix we use compared to the original ASM code. I have prepared two webrevs one at [1] which has the full change and one at [2] for which I have removed a lot of javadoc from the full webrev for reviewers that prefer less javadoc.
>
> Thanks,
> Vicente
>
> PS, thanks to Remi for fixing in a very short time a bug I found in ASM related to the parsing of Record attributes
>
> [1] http://cr.openjdk.java.net/~vromero/8241627/full/webrev.01/
>

From vicente.romero at oracle.com  Tue Apr 14 18:22:09 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 14 Apr 2020 14:22:09 -0400
Subject: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
References: <95d41c62-dba7-240b-a3ce-357568d0f6f7@oracle.com>

Message-ID: <5ca5be03-cbb3-5824-b64e-660d06cfd75b@oracle.com>

Hi Paul,

On 4/14/20 2:05 PM, Paul Sandoz wrote:
> Hi Vicente,
>
> Looks ok from the changes required to integrate into the JDK.
>
> Maybe the @SuppressWarnings warning annotations could be upstreamed?

do you mean to ask ASM team to include them? Sorry that I wasn't more
specific, the warnings come from the use of experimental APIs (intended
for JDK preview features), they have used to approach of "deprecating"
the experimental APIs

>
> Paul.

Vicente

>
>
>> On Apr 13, 2020, at 8:05 AM, Vicente Romero  wrote:
>>
>> Hi all,
>>
>> Please review this patch that updates the ASM version to appear in JDK15 (from 7.0 to 8.0). Version 8.0 is compatible with JDK14 plus it has several experimental APIs to cover records and sealed types. We have also updated a number of tests (mostly record oriented tests) to use the updated APIs. Thanks to Igor Ignatyev for his help in particular for finding the source and fixing an issue that was provoking a failure at test:
>>
>> open/test/jdk/jdk/jfr/jvm/TestLogOutput.java
>>
>> This is the only substantial change that makes our copy of ASM different from the original, apart from several @SuppressWarnings that were added for the build to pass. The patch from Igor is this:
>>
>> diff -r b2ca6a37c16b src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
>> --- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 07:04:27 2020 -0700
>> +++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 17:14:59 2020 -0700
>> @@ -222,15 +222,15 @@
>>       }
>>
>>       static boolean isWhitelisted(final String internalName) {
>> -        if (!internalName.startsWith("org/objectweb/asm/")) {
>> +        if (!internalName.startsWith("jdk/internal/org/objectweb/asm/")) {
>>               return false;
>>           }
>>           String member = "(Annotation|Class|Field|Method|Module|RecordComponent|Signature)";
>>           return internalName.contains("Test\$")
>>                   || Pattern.matches(
>> -                        "org/objectweb/asm/util/Trace" + member + "Visitor(\\\$.*)?", internalName)
>> + "jdk/internal/org/objectweb/asm/util/Trace" + member + "Visitor(\\\$.*)?", internalName)
>>                   || Pattern.matches(
>> -                        "org/objectweb/asm/util/Check" + member + "Adapter(\\\$.*)?", internalName);
>> + "jdk/internal/org/objectweb/asm/util/Check" + member + "Adapter(\\\$.*)?", internalName);
>>       }
>>
>>       static void checkIsPreview(final InputStream classInputStream) {
>>
>>
>> And it is basically adapting our copy to the different package prefix we use compared to the original ASM code. I have prepared two webrevs one at [1] which has the full change and one at [2] for which I have removed a lot of javadoc from the full webrev for reviewers that prefer less javadoc.
>>
>> Thanks,
>> Vicente
>>
>> PS, thanks to Remi for fixing in a very short time a bug I found in ASM related to the parsing of Record attributes
>>
>> [1] http://cr.openjdk.java.net/~vromero/8241627/full/webrev.01/
>>

From paul.sandoz at oracle.com  Tue Apr 14 18:42:51 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Apr 2020 11:42:51 -0700
Subject: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
References: <95d41c62-dba7-240b-a3ce-357568d0f6f7@oracle.com>

<5ca5be03-cbb3-5824-b64e-660d06cfd75b@oracle.com>
Message-ID: <9DF5B56D-8F42-4351-9B5C-44B316EFE7CB@oracle.com>

> On Apr 14, 2020, at 11:22 AM, Vicente Romero  wrote:
>
> Hi Paul,
>
> On 4/14/20 2:05 PM, Paul Sandoz wrote:
>> Hi Vicente,
>>
>> Looks ok from the changes required to integrate into the JDK.
>>
>> Maybe the @SuppressWarnings warning annotations could be upstreamed?
>
> do you mean to ask ASM team to include them?

Yes.

> Sorry that I wasn't more specific, the warnings come from the use of experimental APIs (intended for JDK preview features), they have used to approach of "deprecating" the experimental APIs
>

Ah, I see now, I should have looked more closely.  I guess it?s a policy decision for the ASM maintainers, since ASM has to depend internally on some experimental components, say Opcodes.ASM9_EXPERIMENTAL.

Paul.

From vicente.romero at oracle.com  Tue Apr 14 18:49:44 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 14 Apr 2020 14:49:44 -0400
Subject: RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
References: <95d41c62-dba7-240b-a3ce-357568d0f6f7@oracle.com>

<5ca5be03-cbb3-5824-b64e-660d06cfd75b@oracle.com>
<9DF5B56D-8F42-4351-9B5C-44B316EFE7CB@oracle.com>
Message-ID: <07b18fe8-6568-0631-6be2-f02c9ee1f28f@oracle.com>

On 4/14/20 2:42 PM, Paul Sandoz wrote:
>
>> On Apr 14, 2020, at 11:22 AM, Vicente Romero  wrote:
>>
>> Hi Paul,
>>
>> On 4/14/20 2:05 PM, Paul Sandoz wrote:
>>> Hi Vicente,
>>>
>>> Looks ok from the changes required to integrate into the JDK.
>>>
>>> Maybe the @SuppressWarnings warning annotations could be upstreamed?
>> do you mean to ask ASM team to include them?
> Yes.
>
>
>> Sorry that I wasn't more specific, the warnings come from the use of experimental APIs (intended for JDK preview features), they have used to approach of "deprecating" the experimental APIs
>>
> Ah, I see now, I should have looked more closely.  I guess it?s a policy decision for the ASM maintainers, since ASM has to depend internally on some experimental components, say Opcodes.ASM9_EXPERIMENTAL.

that's correct
>
> Paul.
Vicente

From paul.sandoz at oracle.com  Tue Apr 14 18:51:44 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Apr 2020 11:51:44 -0700
Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com>
<1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com>

Message-ID: <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com>

Looks good to me (not familiar with all the code areas.

Minor suggestion:

MethodHandles.java

1811          * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}:
1812          *
1813          *  {@link Class#getName()} returns the string {@code GN + "/" + },
1814          *      even though this is not a valid binary class or interface name.
1815          *  {@link Class#descriptorString()} returns the string
1816          *      {@code "L" + N + ";" + "/" +  },
1817          *      even though this is not a valid type descriptor name.
1818          *

?
even though this is not a valid type descriptor name; and

- therefore {@link Class#describeConstable} returns an empty {@code Optional}.
?

?

Paul.

> On Apr 11, 2020, at 8:13 PM, Mandy Chung  wrote:
>
> Please review the delta patch:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/
>
> Incremental specdiff:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html
> This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes.   The proposal is to define the descriptor string for a hidden class of this form:
>     "L" + N + ";" + "/" +
>
> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class.   To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form.     This change affects JVM TI, JDWP and JDI.    The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on.
>
>
>
> Mandy
> [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html
>
> ----------------
> As a record, the above patch is applied on the top:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/
>
> webrev.06 includes the following changes that have been reviewed:
> 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden
> 2. remove unused `setImplMethod` method from lambda proxy class
> 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events
> 4. drop the uniqueness guarantee of the suffix of the hidden class's name
>
> On 3/31/20 8:01 PM, Mandy Chung wrote:
>> Thanks to the review feedbacks.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/
>> Delta between webrev.03 and webrev.04:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/
>>
>> Summary of changes is:
>> 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate
>> 2. Rename Class::isHiddenClass to Class::isHidden
>> 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes
>> 4. Add test case for unloadable class with nest host error
>> 5. Add test cases for hidden classes with different kinds of class or interface
>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class"
>> 7. Small changes in response to Remi, Coleen, Paul's review comments
>> 9. Fix @modules in tests
>>
>> Most of the changes above have also been reviewed as separate patches.
>>
>> Thanks
>> Mandy
>>
>> On 3/26/20 4:57 PM, Mandy Chung wrote:
>>> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area.  Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd.  CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference).
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
>>>
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
>>>
>>> JVMS 5.4.4 change:
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
>>>
>>> CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8238359
>>>
>>> Thanks
>>> Mandy
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502
>>
>

From kralj.mark at gmail.com  Tue Apr 14 17:09:48 2020
From: kralj.mark at gmail.com (Mark Kralj-Taylor)
Date: Tue, 14 Apr 2020 18:09:48 +0100
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

Message-ID:

David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?

The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the deciding
factor on if Hotspot Linux code can call
clock_gettime(CLOCK_REALTIME).

doc/building.md suggests minimum Linux is Oracle Enterprise Linux 6.4
(i.e. RHEL 6.4).
Which I think uses glibc 2.12-1.107 (based on
https://yum.oracle.com/repo/OracleLinux/OL6/4/base/x86_64/index_src.html).
Searching for glibc sources it looks like this supports
clock_gettime(CLOCK_REALTIME).

The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
should be supported if the clock_gettime() API exists. But other clock
sources are not mandatory. So CLOCK_REALTIME should be available even
if CLOCK_MONOTONIC is not.
- See: https://linux.die.net/man/2/clock_gettime.
- Also "POSIX.1-2008 marks gettimeofday() as obsolete, recommending
the use of clock_gettime(2) instead." from:
https://linux.die.net/man/2/gettimeofday

Note that Hotspot os_posix.cpp checks for non-error return from
clock_gettime(CLOCK_MONOTONIC) to guard setting the _clock_gettime
function pointer. Which was why in the patch I called clock_gettime
directly for Linux specific os_linux.cpp (a subset of Posix OS-s).

Also os_linux.cpp has:
#ifndef SUPPORTS_CLOCK_MONOTONIC
#error "Build platform doesn't support clock_gettime and related functionality"
#endif
Which made me wonder if openjdk might require CLOCK_MONOTONIC - which
would mean clock_gettime(CLOCK_REALTIME) is supported.

Mark

On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor  wrote:
>
> Daniel,
> Yes System.currentTimeMillis() and Clock.systemUTC() must be
> consistent, so should use the same OS time source (as shown by ).
>
> The patch to os_linux.cpp ensures this by calling the same Linux API:
> clock_gettime(CLOCK_REALTIME) for both, from:
> - os::javaTimeMillis() that backs System.currentTimeMillis()
> - os::javaTimeSystemUTC() that backs Clock.systemUTC()
>
> Looking at Linux / glibc source I think that gettimeofday() and
> clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource.
> i.e. that given by: cat
> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Mark
>
> On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs  wrote:
> >
> > Hi,
> >
> > On 11/04/2020 00:53, David Holmes wrote:
> > > Update:
> > >> It's a holiday weekend so I can't dig into this right now but we tried
> > >> using a high-precision clock source for systemUTC() in the past but it
> > >> didn't work because systemUTC() and currentTimeMillis() have to use
> > >> the same time base, and currentTimeMillis() has to use gettimeofday().
> > >> I thought this cross-dependency was documented somewhere but can't
> > >> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
> > >> actually have the same time characteristics wrt. wall-clock time then
> > >> changing both as suggested may indeed work.
> >
> > Just to emphasize David's comment: System::currentTimeMillis() and
> > Clock::systemUTC() should use the same time source: if they don't - then
> > some tests will fail, and because it can be tricky to assert things
> > in tests, they might (and probably will) fail only intermittently.
> >
> > I'm probably the culprit here, I added those tests when I upgraded
> > Clock::systemUTC() to report sub millisecond granularity [1] - as was
> > available in the underlying clock that System::currentTimeMillis()
> >
> > However, I think I would be disturbed if System::currentTimeMillis()
> > and Clock::systemUTC() were using different clocks and could
> > report a different notion of time (by drifting away from each other).
> >
> > best regards,
> >
> > -- daniel
> > [1] https://bugs.openjdk.java.net/browse/JDK-8068730

From dmitry.bessonov at oracle.com  Tue Apr 14 19:26:35 2020
From: dmitry.bessonov at oracle.com (Dmitry Bessonov)
Date: Tue, 14 Apr 2020 20:26:35 +0100
Subject: promoting/moving @jdk.internal.PreviewFeature to be a standard JavaSE
API
Message-ID: <252FBC48-CE5C-46EE-8BB8-39BF9A620920@oracle.com>

Hi,

Noticed in the OpenJDK sources that String::stripIndent, String::translateEscapes, String::formatted were annotated with @jdk.internal.PreviewFeature until the very recent time [1].

Are there any plans to move this annotation out of ?jdk? namespace to ?java? or ?javax? namespace?

This movement looks logical as the concept of ?Preview Feature? [2] is not JDK-specific - JEP12 has "Scope: SE? and ?Exposure: Open".

kind regards,
dmitry

[1] http://hg.openjdk.java.net/jdk/jdk/rev/60ec850952da#l1.7
[2] https://bugs.openjdk.java.net/browse/JDK-8195734

From david.holmes at oracle.com  Tue Apr 14 22:32:36 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Apr 2020 08:32:36 +1000
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so
Clock.systemUTC() can give nanosecond precision UTC
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

Message-ID: <9d13d404-ccf3-153c-90ea-9dce1c530c47@oracle.com>

Hi Mark,

On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote:
> David, Daniel,
> What is the oldest (lowest) version of Linux and glibc for openjdk 15?

I'm not clear on that.

> The availability of clock_gettime(CLOCK_REALTIME) on the oldest
> Linux/glibc supported by openjdk 15 is likely to be the deciding
> factor on if Hotspot Linux code can call
> clock_gettime(CLOCK_REALTIME).
>
> doc/building.md suggests minimum Linux is Oracle Enterprise Linux 6.4
> (i.e. RHEL 6.4).
> Which I think uses glibc 2.12-1.107 (based on
> https://yum.oracle.com/repo/OracleLinux/OL6/4/base/x86_64/index_src.html).
> Searching for glibc sources it looks like this supports
> clock_gettime(CLOCK_REALTIME).
>
> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
> should be supported if the clock_gettime() API exists. But other clock
> sources are not mandatory. So CLOCK_REALTIME should be available even
> if CLOCK_MONOTONIC is not.
> - See: https://linux.die.net/man/2/clock_gettime.
> - Also "POSIX.1-2008 marks gettimeofday() as obsolete, recommending
> the use of clock_gettime(2) instead." from:
> https://linux.die.net/man/2/gettimeofday
>
> Note that Hotspot os_posix.cpp checks for non-error return from
> clock_gettime(CLOCK_MONOTONIC) to guard setting the _clock_gettime
> function pointer. Which was why in the patch I called clock_gettime
> directly for Linux specific os_linux.cpp (a subset of Posix OS-s).
>
> Also os_linux.cpp has:
> #ifndef SUPPORTS_CLOCK_MONOTONIC
> #error "Build platform doesn't support clock_gettime and related functionality"
> #endif
> Which made me wonder if openjdk might require CLOCK_MONOTONIC - which
> would mean clock_gettime(CLOCK_REALTIME) is supported.

So we require that the build platform supports CLOCK_MONOTONIC and
clock_gettime, but not that the runtime platform supports
CLOCK_MONOTONIC (without which we don't/didn't need clock_gettime().

So we can switch to using clock_gettime(CLOCK_REALTIME) at build time
with no problem.

We can probably also require clock_gettime(CLOCK_REALTIME) at runtime,
but we need to double-check that. I recall encountering a platform where
clock_gettime was not available, but I can't recall if it was mainstream
or on one of the other OpenJDK projects - nor do I recall exactly how
long ago this was. Keeping the dynamic lookup of clock_gettime would be
a conservative approach here - but we would need to make the distinction
between the ability to use CLOCK_REALTIME and CLOCK_MONOTONIC.

Or someone puts in the time and effort to establish exactly what the
kernel and glibc dependencies are and whether we can just rely on
everything existing on all platforms we care about. I don't have time to
do that nor validate the results if someone else does it.

Cheers,
David

> Mark
>
> On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor  wrote:
>>
>> Daniel,
>> Yes System.currentTimeMillis() and Clock.systemUTC() must be
>> consistent, so should use the same OS time source (as shown by ).
>>
>> The patch to os_linux.cpp ensures this by calling the same Linux API:
>> clock_gettime(CLOCK_REALTIME) for both, from:
>> - os::javaTimeMillis() that backs System.currentTimeMillis()
>> - os::javaTimeSystemUTC() that backs Clock.systemUTC()
>>
>> Looking at Linux / glibc source I think that gettimeofday() and
>> clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource.
>> i.e. that given by: cat
>> /sys/devices/system/clocksource/clocksource0/current_clocksource
>>
>> Mark
>>
>> On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs  wrote:
>>>
>>> Hi,
>>>
>>> On 11/04/2020 00:53, David Holmes wrote:
>>>> Update:
>>>>> It's a holiday weekend so I can't dig into this right now but we tried
>>>>> using a high-precision clock source for systemUTC() in the past but it
>>>>> didn't work because systemUTC() and currentTimeMillis() have to use
>>>>> the same time base, and currentTimeMillis() has to use gettimeofday().
>>>>> I thought this cross-dependency was documented somewhere but can't
>>>>> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
>>>>> actually have the same time characteristics wrt. wall-clock time then
>>>>> changing both as suggested may indeed work.
>>>
>>> Just to emphasize David's comment: System::currentTimeMillis() and
>>> Clock::systemUTC() should use the same time source: if they don't - then
>>> some tests will fail, and because it can be tricky to assert things
>>> in tests, they might (and probably will) fail only intermittently.
>>>
>>> I'm probably the culprit here, I added those tests when I upgraded
>>> Clock::systemUTC() to report sub millisecond granularity [1] - as was
>>> available in the underlying clock that System::currentTimeMillis()
>>>
>>> However, I think I would be disturbed if System::currentTimeMillis()
>>> and Clock::systemUTC() were using different clocks and could
>>> report a different notion of time (by drifting away from each other).
>>>
>>> best regards,
>>>
>>> -- daniel
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730

From ioi.lam at oracle.com  Tue Apr 14 22:34:41 2020
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 14 Apr 2020 15:34:41 -0700
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:
Message-ID: <7acb8853-a779-1d96-02c3-0b94a32050b0@oracle.com>

On 4/13/20 12:26 PM, Eirik Bj?rsn?s wrote:
> Hi,
>
> While working on improvements to JarFile.getVersionedEntry, it occurred to
> me that the missing lookups we are removing there may be just one example
> of a more general issue.
>
> To get a better understanding of how ZipFile.getEntry is used, I added some
> PerfCounters for the number of hits and misses in calls to
> ZipFile.Source.getEntryPos() and the elapsed run times for these hits and
> misses.
>
> To test this I used Spring PetClinic. I only care about startup time here,
> since that's when most of the Zip lookups happens.
>
> Here's what I found:
>
> Hits 10776, misses: 744642
> => 1.4 percent of lookups are hits
>
I am a little worried adding extra overhead unconditionally into the JAR
reader that people may not need/want.

Maybe we should take a step back and see why there are so many misses?
Is it because you have a long classpath with many JARs on it, and you
end up searching a lot of JAR files unnecessarily?

If this is the case, I think converting the app to modules will give you
the speed up. A package can exist only in a single module so lookup is
fast. You won't have misses unless you intentionally look for things
that don't exist.

Or, you can just package the app into one giant JAR file.

Thanks
- Ioi

>
> Hits runtime: 7995508 ns, miss runtime: 328360900 ns
> => 2.4 percent of run time is spent on hits.
>
> The startup time reported by Spring Petclinic was 6395 ms. 5 percent of
> this startup time was spent on missed getEntry lookups.
>
> If we can improve the performance of lookup misses, I think there is a good
> potential for overall performance wins.
>
> One idea I had about how this could be done was to use Bloom filters. Bloom
> filters provide a fast, space-efficient, probabilistic data structure which
> may be used to determine that an element is definitely not a member of a
> set.
>
> I made a sloppy Bloom filter implementation and updated
> ZipFile.Source.getEntryPos to check this filter first and return -1 if the
> name is definitely not in the jar.
>
> This gave the following results for Spring Petclinic startup:
>
> Hits run time: 10964825 ns, miss runtime: 233868876 ns
>
> We see that while hits are now 1.4x slower, the total time spent on lookups
> is only 73 percent compared to that of the baseline.
>
> This translates to a Petclinic startup improvement of 91 ms or 1.4 percent
>
> I expect that this can be improved further with a more clever use of hash
> functions. Specifically it would be great to skip earlier in case of a
> miss, before the String to byte[] encoding happens. Also, I haven't
> analysed the false positive rate in the bloom filter, so that's probably
> open for some tuning.
>
> I also expect lookup misses to be even more common on applications with
> longer class paths and more complex class loader delegation.
>
> Cheers,
> Eirik.

From claes.redestad at oracle.com  Tue Apr 14 23:19:57 2020
Date: Wed, 15 Apr 2020 01:19:57 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:
<7acb8853-a779-1d96-02c3-0b94a32050b0@oracle.com>
Message-ID: <37fc2a0c-0263-db0c-c32e-3c4fc2be94c1@oracle.com>

On 2020-04-15 00:34, Ioi Lam wrote:
>>
> I am a little worried adding extra overhead unconditionally into the JAR
> reader that people may not need/want.
>
> Maybe we should take a step back and see why there are so many misses?
> Is it because you have a long classpath with many JARs on it, and you
> end up searching a lot of JAR files unnecessarily?
>
> If this is the case, I think converting the app to modules will give you
> the speed up. A package can exist only in a single module so lookup is
> fast. You won't have misses unless you intentionally look for things
> that don't exist.
>
> Or, you can just package the app into one giant JAR file.

Yes, I think the constraint on any optimizations here is that it
shouldn't regress anything we can think of. Especially not already-
optimized deployments - be they using modularized apps, fat jars or
AppCDS.

But I think we should improve the lowest common denominator OOTB
experience when we can. And after some back and forth with Eirik off-
list I think there are improvements we can do in this area which will be
wins for many and a regression for no-one (at least not in any
detectable way).

A bloom filter might not be it, since it would add noticeable overhead
for fat jar deployments. So... stay tuned..? :-)

Thanks!

/Claes

From adinn at redhat.com  Wed Apr 15 09:01:53 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 15 Apr 2020 10:01:53 +0100
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:
<7acb8853-a779-1d96-02c3-0b94a32050b0@oracle.com>
Message-ID: <7ac1bd95-8f92-9d16-a29a-eb715170a278@redhat.com>

On 14/04/2020 23:34, Ioi Lam wrote:
> I am a little worried adding extra overhead unconditionally into the JAR
> reader that people may not need/want.

A reasonable worry. We should always try to avoid fixes that benefit a
majority if they 'punish' a minority . . .

> Maybe we should take a step back and see why there are so many misses?
> Is it because you have a long classpath with many JARs on it, and you
> end up searching a lot of JAR files unnecessarily?

Well, there are a fair few as can be identified simply by Googling the pom

https://github.com/spring-projects/spring-petclinic/blob/master/pom.xml

and reading the dependencies section. n.b. that only shows top-level
dependencies but not recursive ones.

Unfortunately, this is going to be the reality for a many existing and
new apps. Most production Java apps are built from many library jars.
Java is the biggest 'divide and conquer' programming eco-system we have
ever seen in the history of computing. That's a direct corollary of it
being the biggest eco-system we have ever seen -- scale /necessitates/
divide and conquer.

> If this is the case, I think converting the app to modules will give you
> the speed up. A package can exist only in a single module so lookup is
> fast. You won't have misses unless you intentionally look for things
> that don't exist.

Well, yes but that also is just not going to fly for the majority of
Java developers for the reason given above. Most app developers are not
in a position to modularize their apps because the libraries they depend
on are not modularized, because the libraries /they/ depend on are not
modularized, because the libraries /they/ depend on are not modularized
... and so on. It's rarely going to be one group or organization with
one fixed goal that would need to schedule and implement such a change.

Now, you may lament that situation (or not) but it /is/ a brute fact and
is going to remain the status quo for a very long time. An eco-system of
the size of Java is like an ocean-liner. Which means the above advice is
going to whistle over the heads of many Java developers.

> Or, you can just package the app into one giant JAR file.
Again, that completely misses the reality of most developer's circumstances.

Now, I hope I don't come across like I am simply being negative here. I
have posted this reply because it's critically important that we, the
OpenJDK project devs, understand and keep in mind how most app
developers use (are able to use) Java. Suggestions that bypass the
realities and limitations of that usage say to me that we are at risk of
not meeting those users' needs.

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 eirbjo at gmail.com  Wed Apr 15 09:41:57 2020
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 15 Apr 2020 11:41:57 +0200
Subject: Improving ZipFile.getEntry performance using Bloom filters
References:
<7acb8853-a779-1d96-02c3-0b94a32050b0@oracle.com>
<7ac1bd95-8f92-9d16-a29a-eb715170a278@redhat.com>
Message-ID:

>
> Unfortunately, this is going to be the reality for a many existing and
> new apps. Most production Java apps are built from many library jars.
> Java is the biggest 'divide and conquer' programming eco-system we have
> ever seen in the history of computing.

Andrew,

Thanks for providing some context! This resonated well with my 15 years
experience Java enterprise development.

Just to clarify: My goal with this effort is not to speed up Spring
Petclinic. It is to improve life for the larger Java ecosystem as
described by Andrew.

So while advice on how to speed up Spring Petclinic is nice, it does kind
of miss the point.

Cheers,
Eirik.

From fw at deneb.enyo.de  Wed Apr 15 09:47:27 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 15 Apr 2020 11:47:27 +0200
Subject: os::javaTimeSystemUTC to call nanosecond precision OS API,
so Clock.systemUTC() can give nanosecond precision UTC
In-Reply-To: <87sgh6klz7.fsf@mid.deneb.enyo.de> (Florian Weimer's message of
"Tue, 14 Apr 2020 19:37:00 +0200")
References:
<0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com>
<9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com>

<87sgh6klz7.fsf@mid.deneb.enyo.de>
Message-ID: <87sgh5jd1s.fsf@mid.deneb.enyo.de>

* Florian Weimer:

> * Mark Kralj-Taylor:
>
>> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
>> should be supported if the clock_gettime() API exists. But other clock
>> sources are not mandatory.
>
> Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
> gettimeofday, yes.
>
> clock_gettime was already in Linux 2.12 (and possibly quite a bit

That should have been Linux 2.6.12, sorry.

> earlier, I did not check), so that is not likely to be a limitation.
>
> A tricky question is whether it's possible to avoid loading librt.
> The present code already uses dlopen, but I think it could try a
> little bit harder (try resolving clock_gettime first, and then load
> librt, and try again).  For distribution builds that do not need to be
> compatible with glibc versions before 2.17, directly calling
> clock_gettime would also be an option. (clock_gettime moved to
> libc.so.6 in glibc 2.17, but a lot of software keeps linking against
> librt for the definition of clock_gettime, something that we are
> finally tackling on the glibc side.)
>
> Making a direct system call instead is a bit tricky because it's
> absolutely required to use the vDSO if possible, for performance
> reasons.  But it's possible to obtain the address of the vDSO function
> using dlvsym, so that might be an option as well.

From jorn.vernee at oracle.com  Wed Apr 15 10:17:35 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 15 Apr 2020 12:17:35 +0200
Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and
Short implement Constable
References:
<2e10bbbe-1faf-f4a8-d04b-88151a4e1122@oracle.com>
Message-ID: <62f0c7e9-3414-9b0c-c1d0-cc9c5c9dc671@oracle.com>

Thanks, Paul and John, for the CSR reviews.

http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/index.html

Jorn

On 14/04/2020 18:18, Jorn Vernee wrote:
> Hi David,
>
> Thanks for the heads up! A CSR for this patch was created here:
> https://bugs.openjdk.java.net/browse/JDK-8241667
>
> It was moved to 'provisional' today, but still requires one or more
> engineer reviews.
>
> Could someone here review the CSR?
>
> Thanks,
> Jorn
>
> On 18/03/2020 22:59, David Holmes wrote:
>> Hi Jorn,
>>
>> This needs a CSR request before it can be pushed.
>>
>> Thanks,
>> David
>>
>> On 19/03/2020 12:08 am, Jorn Vernee wrote:
>>> Hi,
>>>
>>> Byte, and Short implement Constable?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
>>> Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/
>>>
>>> Having the other box types implement Constable makes them easier to
>>> use with APIs that accept any Constable. Though I'm mostly
>>> interesting in boolean, for which I'm currently falling back to
>>> "true" & "false" strings, but the downside is that this also
>>> requires parsing the string again and having to deal with random
>>> other strings.
>>>
>>> This patch also adds the ConstantBootstraps::convert method that is
>>> used to facilitate the conversion from int to (short|char|byte).
>>> This currently takes a source type explicitly. In practice, it seems
>>> that Object can always be used as a source type for the same
>>> behavior, but explicitly specifying source and destination types
>>> seems more robust to me in case this behavior ever changes, or we
>>> want to expand on the supported kinds of conversion. (for instance
>>> it is currently not possible to convert from an int to a Long
>>> directly, or from Short to Integer, but maybe those cases could be
>>> supported in the future as well).
>>>
>>> Testing: tier1-3 & downstream testing for my particular use case
>>>
>>> Thanks,
>>> Jorn
>>>

From pavel.rappo at oracle.com  Wed Apr 15 11:06:46 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 12:06:46 +0100
References:

<98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>

<912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
<9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>

<5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID:

Vipin,

I saw that Max had already reviewed that incremental patch. That's good.

I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
(International Components for Unicode) package. Once this has been cleared by
experts in that area, we are good to go.

Here's the cumulative webrev:

http://cr.openjdk.java.net/~prappo/8242366/webrev.01/

-Pavel

> On 11 Apr 2020, at 20:23, Vipin Sharma  wrote:
>
> Hi Pavel,
>
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo  wrote:
>>
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>
>
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
>
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the `X509Certificate` to be checked
> +     * @param cert the `X509Certificate` to be checked
>      * @param prevKey the `PublicKey` that failed
>      * @param signFlag `true` if that key was trusted to sign CRLs
>      * @param stackedCerts a `Set` of `X509Certificate`s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
>
>
>>> On 8 Apr 2020, at 17:35, Vipin Sharma  wrote:
>>>
>>>
>>>
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo  wrote:
>>>>
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>
>>>> -Pavel
>>>
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>
>>>>
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman  wrote:
>>>>>
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>>
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>
>>>>> -Alan
>>>>
>>>
>>> Regards,
>>> Vipin
>>
> Regards,
> Vipin
>

From claes.redestad at oracle.com  Wed Apr 15 12:58:35 2020
Date: Wed, 15 Apr 2020 14:58:35 +0200
Subject: RFR: 8242842: Avoid reallocating name when checking for trailing
slash in ZipFile.getEntryPos
Message-ID: <115989cd-0d2b-a766-117f-b38babeff344@oracle.com>

Hi,

a trivial optimization to ZipFile.getEntryPos extracted from some
experiments conducted mostly by Eirik Bj?rsn?s.

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

This removes an extra array copy on every miss, and the patch means a
small speed-up on a few startup applications I've tested (Spring
Petclinic: ~50ms faster).

This is an optimization which was lost in translation when porting from
native to Java[1] in JDK 9. The native implementation allocates an
array that can fit the extra '/' if needed, and updates the array in
place for the follow-up check.

Thanks!

/Claes

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

From lance.andersen at oracle.com  Wed Apr 15 13:48:37 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Apr 2020 09:48:37 -0400
Subject: RFR: 8242842: Avoid reallocating name when checking for trailing
slash in ZipFile.getEntryPos
References: <115989cd-0d2b-a766-117f-b38babeff344@oracle.com>
Message-ID: <37C42C99-91F3-40AF-A49B-D3A2AFDF6468@oracle.com>

Hi Claes,

I think this looks good overall.

Vwar
LNXW

> On Apr 15, 2020, at 8:58 AM, Claes Redestad  wrote:
>
> Hi,
>
> a trivial optimization to ZipFile.getEntryPos extracted from some
> experiments conducted mostly by Eirik Bj?rsn?s.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8242842
>
> This removes an extra array copy on every miss, and the patch means a
> small speed-up on a few startup applications I've tested (Spring
> Petclinic: ~50ms faster).
>
> This is an optimization which was lost in translation when porting from
> native to Java[1] in JDK 9. The native implementation allocates an
> array that can fit the extra '/' if needed, and updates the array in
> place for the follow-up check.
>
> Thanks!
>
> /Claes
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8145260

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 Alan.Bateman at oracle.com  Wed Apr 15 13:52:01 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Apr 2020 14:52:01 +0100
Subject: RFR: 8242842: Avoid reallocating name when checking for trailing
slash in ZipFile.getEntryPos
References: <115989cd-0d2b-a766-117f-b38babeff344@oracle.com>
Message-ID:

On 15/04/2020 13:58, Claes Redestad wrote:
> Hi,
>
> a trivial optimization to ZipFile.getEntryPos extracted from some
> experiments conducted mostly by Eirik Bj?rsn?s.
>
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242842
>
> This removes an extra array copy on every miss, and the patch means a
> small speed-up on a few startup applications I've tested (Spring
> Petclinic: ~50ms faster).
>
> This is an optimization which was lost in translation when porting from
> native to Java[1] in JDK 9. The native implementation allocates an
> array that can fit the extra '/' if needed, and updates the array in
> place for the follow-up check.
Good sleuthing! I remember that code in zip_util.c and it looks like the
re-write didn't bring it over completely. The webrev looks good.

-Alan

From claes.redestad at oracle.com  Wed Apr 15 14:05:19 2020
Date: Wed, 15 Apr 2020 16:05:19 +0200
Subject: RFR: 8242842: Avoid reallocating name when checking for trailing
slash in ZipFile.getEntryPos
References: <115989cd-0d2b-a766-117f-b38babeff344@oracle.com>

Message-ID: <18bd5ba1-1e44-cae0-c2f8-cda47aa8b812@oracle.com>

Lance, Alan,

thanks for reviewing!

I think there's more things we can improve in this area, but will move

/Claes

On 2020-04-15 15:52, Alan Bateman wrote:
>
>
> On 15/04/2020 13:58, Claes Redestad wrote:
>> Hi,
>>
>> a trivial optimization to ZipFile.getEntryPos extracted from some
>> experiments conducted mostly by Eirik Bj?rsn?s.
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8242842
>>
>> This removes an extra array copy on every miss, and the patch means a
>> small speed-up on a few startup applications I've tested (Spring
>> Petclinic: ~50ms faster).
>>
>> This is an optimization which was lost in translation when porting from
>> native to Java[1] in JDK 9. The native implementation allocates an
>> array that can fit the extra '/' if needed, and updates the array in
>> place for the follow-up check.
> Good sleuthing! I remember that code in zip_util.c and it looks like the
> re-write didn't bring it over completely. The webrev looks good.
>
> -Alan

From sundararajan.athijegannathan at oracle.com  Wed Apr 15 15:56:37 2020
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 15 Apr 2020 21:26:37 +0530
Subject: RFR 8241749: Remove the Nashorn JavaScript Engine
Message-ID:

Nashorn script engine modules (jdk.scripting.nashorn,
jdk.scripting.nashorn.shell) and jjs tool are removed.

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

JEP: https://openjdk.java.net/jeps/372

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

Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html

Few tests that use nashorn are worked around by @ignore or deleting
relevant nashorn test sections. Separate test bugs have been filed to
handle these.

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

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

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

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

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

Thanks,

-Sundar

From james.laskey at oracle.com  Wed Apr 15 16:07:29 2020
Date: Wed, 15 Apr 2020 13:07:29 -0300
Subject: RFR 8241749: Remove the Nashorn JavaScript Engine
References:
Message-ID: <41A57690-210E-417B-97CA-E8F9EE0E5546@oracle.com>

+1

> On Apr 15, 2020, at 12:56 PM, sundararajan.athijegannathan at oracle.com wrote:
>
>
> Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell) and jjs tool are removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241749
>
> JEP: https://openjdk.java.net/jeps/372
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8241751
>
> Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html
>
> Few tests that use nashorn are worked around by @ignore or deleting relevant nashorn test sections. Separate test bugs have been filed to handle these.
>
> https://bugs.openjdk.java.net/browse/JDK-8242860
>
> https://bugs.openjdk.java.net/browse/JDK-8242859
>
> https://bugs.openjdk.java.net/browse/JDK-8242858
>
> https://bugs.openjdk.java.net/browse/JDK-8241982
>
> https://bugs.openjdk.java.net/browse/JDK-8235594
>
> Thanks,
>
> -Sundar
>
>

From pavel.rappo at oracle.com  Wed Apr 15 16:52:47 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 17:52:47 +0100
References:

<98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>

<912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
<9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>

<5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>

Message-ID:

Vipin,

After a private exchange with Naoto Sato, who is fluent in that area, I decided
to leave out all the changes to the jdk.internal.icu package from the changeset.

The reason is quite simple. A significant portion of code in jdk.internal.icu
comes from an upstream project, ICU4J. Making OpenJDK-local changes to it makes
it harder to merge when updating from upstream.

Before I created that latter webrev I found that there were OpenJDK-local
changes to that package. Still, the argument holds and we should not aggravate

-Pavel

P.S. If you care about those changes, you may want to ask ICU4J [^1] folk to
incorporate them. If they agree, one day those changes may show up in the OpenJDK.

----------
[^1]: https://github.com/unicode-org/icu/tree/master/icu4j

> On 15 Apr 2020, at 12:06, Pavel Rappo  wrote:
>
> Vipin,
>
> I saw that Max had already reviewed that incremental patch. That's good.
>
> I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
> (International Components for Unicode) package. Once this has been cleared by
> experts in that area, we are good to go.
>
> Here's the cumulative webrev:
>
>    http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
>
> -Pavel
>
>> On 11 Apr 2020, at 20:23, Vipin Sharma  wrote:
>>
>> Hi Pavel,
>>
>>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo  wrote:
>>>
>>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>>
>>
>> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
>> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
>> @@ -142,7 +142,7 @@
>>       /**
>>        * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>>        * data the index array offset of the indexes for that lead surrogate.
>> -        * @param property data value for a surrogate from the trie, including
>> +        * @param value data value for a surrogate from the trie, including
>>        *        the folding offset
>>        * @return data offset or 0 if there is no data for the lead surrogate
>>        */
>> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -39,7 +39,7 @@
>>
>>    /**
>>     * Calls FilterInputStream's constructor.
>> -     * @param an InputStream
>> +     * @param is an InputStream
>>     */
>>    PlainTextInputStream(InputStream is) {
>>        super(is);
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -881,7 +881,7 @@
>>     * only CRLs signed with a different key (but the same issuer
>>     * name) as the certificate being checked.
>>     *
>> -     * @param currCert the `X509Certificate` to be checked
>> +     * @param cert the `X509Certificate` to be checked
>>     * @param prevKey the `PublicKey` that failed
>>     * @param signFlag `true` if that key was trusted to sign CRLs
>>     * @param stackedCerts a `Set` of `X509Certificate`s>
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -166,7 +166,7 @@
>>    /**
>>     * Creates a URICertStore.
>>     *
>> -     * @param parameters specifying the URI
>> +     * @param params parameters specifying the URI
>>     */
>>    URICertStore(CertStoreParameters params)
>>        throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
>> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
>> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -483,7 +483,7 @@
>>         * and its corresponding CertId.
>>         *
>>         * @param subjectCert the certificate to be checked for revocation
>> -         * @param cid the CertId for {@code subjectCert}
>> +         * @param certId the CertId for {@code subjectCert}
>>         */
>>        StatusInfo(X509Certificate subjectCert, CertId certId) {
>>            cert = subjectCert;
>> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
>> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -193,7 +193,7 @@
>>    /**
>>     * Constructs an object to store the response to a timestamp request.
>>     *
>> -     * @param status A buffer containing the ASN.1 BER encoded response.
>> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>>     * @throws IOException The exception is thrown if a problem is encountered
>>     *         parsing the timestamp response.
>>     */
>>
>>
>>>> On 8 Apr 2020, at 17:35, Vipin Sharma  wrote:
>>>>
>>>>
>>>>
>>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo  wrote:
>>>>>
>>>>> Why assume something that sophisticated where it can be adequately explained by
>>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>>
>>>>> -Pavel
>>>>
>>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>>
>>>>>
>>>>>> On 8 Apr 2020, at 14:14, Alan Bateman  wrote:
>>>>>>
>>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>>> Hi Pavel,
>>>>>>>
>>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>>> nor imported
>>>>>>>
>>>>>>> Hopefully that's only on internal classes.
>>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>>
>>>>>> -Alan
>>>>>
>>>>
>>>> Regards,
>>>> Vipin
>>>
>> Regards,
>> Vipin
>>
>

From magnus.ihse.bursie at oracle.com  Wed Apr 15 17:14:59 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 15 Apr 2020 19:14:59 +0200
Subject: RFR 8241749: Remove the Nashorn JavaScript Engine
References:
Message-ID: <52443270-e84c-8711-2484-24615eb445da@oracle.com>

On 2020-04-15 17:56, sundararajan.athijegannathan at oracle.com wrote:
>
> Nashorn script engine modules (jdk.scripting.nashorn,
> jdk.scripting.nashorn.shell) and jjs tool are removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241749
>
> JEP: https://openjdk.java.net/jeps/372
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8241751
>
> Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html
Build changes look almost OK. However, in make/RunTests.gmk, you have
removed this:

-hotspot_JTREG_PROBLEM_LIST += \$(TOPDIR)/test/hotspot/jtreg/ProblemList.txt

which should stay.

/Magnus

> Few tests that use nashorn are worked around by @ignore or deleting
> relevant nashorn test sections. Separate test bugs have been filed to
> handle these.
>
> https://bugs.openjdk.java.net/browse/JDK-8242860
>
> https://bugs.openjdk.java.net/browse/JDK-8242859
>
> https://bugs.openjdk.java.net/browse/JDK-8242858
>
> https://bugs.openjdk.java.net/browse/JDK-8241982
>
> https://bugs.openjdk.java.net/browse/JDK-8235594
>
> Thanks,
>
> -Sundar
>
>

From volker.simonis at gmail.com  Wed Apr 15 17:48:03 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 15 Apr 2020 19:48:03 +0200
Subject: RFR(S): 8242848: Improve performance of InflaterOutputStream.write()
Message-ID:

Hi,

can I please have a review for the following simple performance enhancement:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848/
https://bugs.openjdk.java.net/browse/JDK-8242864

InflaterOutputStream has an internal buffer which is used for the
inflated data. This buffer can be configured to a custom size (the
default is 512 bytes) by using the specialized
"InflaterOutputStream(OutputStream out, Inflater infl, int bufLen)"
constructor. A bigger buffer, results in fewer native calls to
"write()" on the associated OutputStream and better overall
performance.

Unfortunately "InflaterOutputStream.write(byte[] b, int off, int len)"
unnecessarily chunks its own byte input buffer "b" into pieces of
maximum 512 bytes before feeding them to the underlying Inflater. This
unnecessarily increases the number of native calls to
Inflater.inflate() and limits the benefit of the configurable internal
buffer to a size of ~(512 * compression-ratio) bytes.

Instead, we could easily pass the complete input buffer "b" as input
to the underlying Inflater. This simplifies the code and results in up
to ~25% performance improvements for bigger internal buffers (see the
JMH benchmark attached to the bug).

Regarding the implementation, I initially wanted to completely remove
the "for (;;)" loop after removing the chunking of the input buffer.
But I think it is still necessary, because an InflaterOutputStream can
be created with a custom Inflater which already has some input data.
In that case, the Inflater will first consume its initial input data
in the first "for" loop iteration while "write()"s input buffer "b"
will only be consumed in the second "for" loop iteration.

While doing this change, I've also realized that all the streams in
java.util.zip (i.e. DeflaterInputStream, GZIPInputStream,
GZIPOutputStream, InflaterInputStream, DeflaterOutputStream) use an
internal byte buffer of 512 bytes by default. Looking at the benchmark
attached to JDK-8242864, I think that increasing this default to a
bigger size (e.g. 4096 bytes) will considerably speed up (up to 50%)
read and write operations on these streams when they are created with
the default buffer size. I think the value "512" is a legacy of old
times when memory was more precious :) so  I've opened "JDK-8242864:
Increase the default, internal buffer size of the Streams in
java.util.zip" to track that as as separate issue. Do you think it
makes sense to increase that default value?

Thank you and best regards,
Volker

PS: do you think it makes sense to contribute the benchmark attached
to JDK-8242864 to the code-tools/mh-jdk-microbenchmarks [1] project?

[1] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/

From alexey.semenyuk at oracle.com  Wed Apr 15 18:13:33 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 15 Apr 2020 14:13:33 -0400
Subject: RFR: JDK-8232935: jpackage failed with NPE whenever
--file-associations provided
References: <8c605f59-7b7d-b378-b82e-b8acbf17223d@oracle.com>
Message-ID: <7abe8d14-94f8-d30c-147f-cd89f710dc13@oracle.com>

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

Move function checking values of mime types in file associations from
Linux to shared code. Added jtreg tests to cover use cases when no or
multiple mime types are specified for file associations.

- Alexey

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

[2]?http://cr.openjdk.java.net/~asemenyuk/8232935/webrev.00

From naoto.sato at oracle.com  Wed Apr 15 18:14:29 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Apr 2020 11:14:29 -0700
Subject: RFR: 8241055: Regex Grapheme Matcher Performance Depends too much
on Total Input Sequence Size
References: <76d3dbae877bf81bf3841fbefe01c4b956832074.camel@paratix.ch>

Message-ID:

Hi Philipp,

Thanks for the update. I like you enriched the RegExTest.java. Two nits:

- RegExTest.java at line 4805: I'd use parentheses for this return
statement.

- PatternBench.java should keep the original copyright year, i.e.,
"2020," -> "2019, 2020,"

Otherwise, it looks good.

Naoto

On 4/14/20 9:26 AM, Philipp Kunz wrote:
> Hi Naoto,
>
> I agree, see attached patch.
>
> Regards,
> Philipp
>
>
> On Thu, 2020-03-26 at 14:14 -0700, naoto.sato at oracle.com wrote:
>> Hi Philipp,
>>
>> I looked at the patch, and it looks good to me. As to the test case,
>> since it is measuring the performance, I would make it in a JMH test.
>> Maybe you would want to put it similar to
>> open/test/micro/org/openjdk/bench/java/util/regex/PatternBench.java
>>
>> Minor suggestion: I would rather rename "getGraphemeType()" to just
>> "getType()", as it is simply retrieving the character type.
>>
>> Naoto
>>
>> On 3/21/20 7:58 AM, Philipp Kunz wrote:
>>> Hi,
>>>
>>> Any opinions on the attached patch or someone tempted to sponsor it?
>>>
>>> Regards,
>>> Philipp

From vipinsharma85 at gmail.com  Wed Apr 15 18:23:10 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Wed, 15 Apr 2020 23:53:10 +0530
References:

<98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>

<912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
<9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>

<5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>

Message-ID: <7E379657-3069-4A46-ACBD-C1AB19AE259D@gmail.com>

Thanks Pavel, I will keep this in mind for future patches.

> On Apr 15, 2020, at 10:22 PM, Pavel Rappo  wrote:
>
> Vipin,
>
> After a private exchange with Naoto Sato, who is fluent in that area, I decided
> to leave out all the changes to the jdk.internal.icu package from the changeset.
>
> The reason is quite simple. A significant portion of code in jdk.internal.icu
> comes from an upstream project,```