From brent.christian at oracle.com Thu Aug 1 00:33:04 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 31 Jul 2019 17:33:04 -0700 Subject: The final optimized version of Dual-Pivot Quicksort (ver.19.1) In-Reply-To: References: <1560893862.105095134@f487.i.mail.ru> <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com>

Message-ID: Thanks, Laurent. I can sponsor this fix, get a RFR thread going for JDK-8226297, keep webrevs updated as the review progresses, etc. However I've uncovered an issue with the fix that should be resolved before proceeding. Specifically, the new Arrays.COMMON_PARALLELISM static constant causes exceptions at startup under some circumstances: * running with LANG=C on Linux[1] * setting a property value with non-Ascii characters on Mac[2] java.util.Arrays is used a fair bit for String handling (java.lang.StringCoding, java.langStringLatin1, etc). The problem is that early in startup, depending on the locale/language setup and/or property settings, java.util.Arrays can be called during initialization of system properties. During Arrays., COMMON_PARALLELISM is setup with a call to ForkJoinPool.getCommonPoolParallelism(). ForkJoinPool sets up some VarHandles, VarHandles leads to MethodHandleStatics., which reads some system properties. But we're still initializing the system properties - 'props' is null, so NPE. I think Arrays.java needs to remove the COMMON_PARALLELISM constant, and go back to making calls to ForkJoinPool.getCommonPoolParallelism(). I can do the update and post an updated webrev (unless further discussion is needed). Thanks, -Brent 1. FWIW, additional JNU_CHECK_EXCEPTION_RETURN calls were needed to produce this stack trace: Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2052) at java.lang.invoke.VarHandles.makeFieldHandle(java.base/VarHandles.java:71) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base/MethodHandles.java:3147) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base/MethodHandles.java:3107) at java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base/MethodHandles.java:2229) at java.util.concurrent.ForkJoinPool.(java.base/ForkJoinPool.java:3184) at java.util.Arrays.(java.base/Arrays.java:436) at java.lang.StringLatin1.newString(java.base/StringLatin1.java:767) at java.lang.StringBuilder.toString(java.base/StringBuilder.java:446) at sun.nio.cs.StandardCharsets.toLower(java.base/StandardCharsets.java:1284) at sun.nio.cs.StandardCharsets.lookup(java.base/StandardCharsets.java:1304) at sun.nio.cs.StandardCharsets.charsetForName(java.base/StandardCharsets.java:1338) at java.nio.charset.Charset.lookup2(java.base/Charset.java:471) at java.nio.charset.Charset.lookup(java.base/Charset.java:460) at java.nio.charset.Charset.isSupported(java.base/Charset.java:501) at jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:233) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54) at java.lang.System.initPhase1(java.base/System.java:2001) Caused by: java.lang.NullPointerException at java.lang.invoke.MethodHandleStatics.(java.base/MethodHandleStatics.java:62) at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2052) at java.lang.invoke.VarHandles.makeFieldHandle(java.base/VarHandles.java:71) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base/MethodHandles.java:3147) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base/MethodHandles.java:3107) at java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base/MethodHandles.java:2229) at java.util.concurrent.ForkJoinPool.(java.base/ForkJoinPool.java:3184) at java.util.Arrays.(java.base/Arrays.java:436) at java.lang.StringLatin1.newString(java.base/StringLatin1.java:767) at java.lang.StringBuilder.toString(java.base/StringBuilder.java:446) at sun.nio.cs.StandardCharsets.toLower(java.base/StandardCharsets.java:1284) at sun.nio.cs.StandardCharsets.lookup(java.base/StandardCharsets.java:1304) at sun.nio.cs.StandardCharsets.charsetForName(java.base/StandardCharsets.java:1338) at java.nio.charset.Charset.lookup2(java.base/Charset.java:471) at java.nio.charset.Charset.lookup(java.base/Charset.java:460) at java.nio.charset.Charset.isSupported(java.base/Charset.java:501) at jdk.internal.util.SystemProps$Raw.platformProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.(java.base/SystemProps.java:233) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:54) at java.lang.System.initPhase1(java.base/System.java:2001) 2. I tried setting java.io.tmpdir to include a non-ascii character (e.g. ? ): Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2052) at java.lang.invoke.VarHandles.makeFieldHandle(java.base/VarHandles.java:71) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base/MethodHandles.java:3140) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base/MethodHandles.java:3100) at java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base/MethodHandles.java:2222) at java.util.concurrent.ForkJoinPool.(java.base/ForkJoinPool.java:3184) at java.util.Arrays.(java.base/Arrays.java:389) at java.lang.StringCoding.decodeUTF8_0(java.base/StringCoding.java:747) at java.lang.StringCoding.decodeUTF8(java.base/StringCoding.java:712) at java.lang.StringCoding.decode(java.base/StringCoding.java:231) at java.lang.String.(java.base/String.java:483) at java.lang.String.(java.base/String.java:553) at jdk.internal.util.SystemProps$Raw.vmProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.cmdProperties(java.base/SystemProps.java:253) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:55) at java.lang.System.initPhase1(java.base/System.java:2001) Caused by: java.lang.NullPointerException at java.lang.invoke.MethodHandleStatics.(java.base/MethodHandleStatics.java:62) at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2052) at java.lang.invoke.VarHandles.makeFieldHandle(java.base/VarHandles.java:71) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base/MethodHandles.java:3140) at java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base/MethodHandles.java:3100) at java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base/MethodHandles.java:2222) at java.util.concurrent.ForkJoinPool.(java.base/ForkJoinPool.java:3184) at java.util.Arrays.(java.base/Arrays.java:389) at java.lang.StringCoding.decodeUTF8_0(java.base/StringCoding.java:747) at java.lang.StringCoding.decodeUTF8(java.base/StringCoding.java:712) at java.lang.StringCoding.decode(java.base/StringCoding.java:231) at java.lang.String.(java.base/String.java:483) at java.lang.String.(java.base/String.java:553) at jdk.internal.util.SystemProps$Raw.vmProperties(java.base/Native Method) at jdk.internal.util.SystemProps$Raw.cmdProperties(java.base/SystemProps.java:253) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:55) at java.lang.System.initPhase1(java.base/System.java:2001) On 7/26/19 1:14 AM, Laurent Bourg?s wrote: > Hi all, > > I updated the DPQS patch thanks to latest release from Vladimir (Pi?ces > jointes2019.07.25): > http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/dpqs-8226297.1/ > > " > Updated version of Arrays and DualPivotQuicksort files, the summary of > changes: > > 1. Corrected minimal threshold for parallelism argument (0 -> 1) > 2. Added constant for common parallelism > 3. Updated byte / char / short counting sort. > " > > Incremental patch change: > http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/diff_dpqs_1_vs_0.log > > Cheers, > Laurent > > > Le?mer. 17 juil. 2019 ??17:12, Laurent Bourg?s > > a ?crit?: > > Hi, > > I integrated locally the complete DPQS 19.2 patch from Vladimir > Yaroslavskiy with up-to-date jdk14 (client) repository: > build OK and jtreg passed OK (java/util/Arrays). > > Here is the corresponding webrev for review: > http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/webrev/ > > Cheers, > Laurent > From naoto.sato at oracle.com Thu Aug 1 00:57:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 31 Jul 2019 17:57:51 -0700 Subject: [14] RFR: 8215181: Accounting currency format support Message-ID: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8215181 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8215181/webrev.00/ This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR. Naoto From dmitry.chuyko at bell-sw.com Thu Aug 1 04:09:30 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 1 Aug 2019 07:09:30 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>

Message-ID: Hi Brent, Le jeu. 1 ao?t 2019 ? 02:32, Brent Christian a ?crit : > Thanks, Laurent. I can sponsor this fix, get a RFR thread going for > JDK-8226297, keep webrevs updated as the review progresses, etc. > Excellent, I will let you and Vladimir work on this review. FYI I have implemented DPQS (int[] ) sorting 2 arrays (values + indices) in the Marlin renderer. It could be generalized to any array type and having the index array is very important in many algorithms... > However I've uncovered an issue with the fix that should be resolved > before proceeding. > > Specifically, the new Arrays.COMMON_PARALLELISM static constant causes > exceptions at startup under some circumstances: > * running with LANG=C on Linux[1] > * setting a property value with non-Ascii characters on Mac[2] > > java.util.Arrays is used a fair bit for String handling > (java.lang.StringCoding, java.langStringLatin1, etc). The problem is > that early in startup, depending on the locale/language setup and/or > property settings, java.util.Arrays can be called during initialization > of system properties. > > During Arrays., COMMON_PARALLELISM is setup with a call to > ForkJoinPool.getCommonPoolParallelism(). ForkJoinPool sets up > some VarHandles, VarHandles leads to > MethodHandleStatics., which reads some system properties. But > we're still initializing the system properties - 'props' is null, so NPE. > Chicken-egg problem. Maybe this field could be wrapped in a getter doing lazy resolution... > I think Arrays.java needs to remove the COMMON_PARALLELISM constant, and > go back to making calls to ForkJoinPool.getCommonPoolParallelism(). > I do not know why Vladimir changed that recently. Any good reason ? > I can do the update and post an updated webrev (unless further > discussion is needed). > PS: I can help on benchmarking as I developped a fair sort benchmark based on JMH: https://github.com/bourgesl/nearly-optimal-mergesort-code JMH test code: https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/src/main/java/edu/sorting/bench I would be interested by improving the perf test code and possibly integrate it in OpenJDK JMH test suite... (later) > Goodbye & good luck, Laurent From vlv.spb.ru at mail.ru Thu Aug 1 09:21:35 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Thu, 01 Aug 2019 12:21:35 +0300 Subject: =?UTF-8?B?UmVbMl06IFRoZSBmaW5hbCBvcHRpbWl6ZWQgdmVyc2lvbiBvZiBEdWFsLVBp?= =?UTF-8?B?dm90IFF1aWNrc29ydCAodmVyLjE5LjEp?= In-Reply-To: References: <1560893862.105095134@f487.i.mail.ru>

Message-ID: <1564651295.280359324@f407.i.mail.ru> Hi Brent, see my comments inline: >???????, 1 ??????? 2019, 9:23 +03:00 ?? Laurent Bourg?s : > >Hi Brent, > >Le jeu. 1 ao?t 2019 ? 02:32, Brent Christian < brent.christian at oracle.com > a ?crit?: >>Thanks, Laurent.? I can sponsor this fix, get a RFR thread going for >>JDK-8226297, keep webrevs updated as the review progresses, etc. Thank you for review! > >Excellent, I will let you and Vladimir work on this review.? > >FYI I have implemented DPQS (int[] ) sorting 2 arrays (values + indices) in the Marlin renderer. It could be generalized to any array type and having the index array is very important in many algorithms...? > >> >>However I've uncovered an issue with the fix that should be resolved >>before proceeding. >> >>Specifically, the new Arrays.COMMON_PARALLELISM static constant causes >>exceptions at startup under some circumstances: >>? ? ?* running with LANG=C on Linux[1] >>? ? ?* setting a property value with non-Ascii characters on Mac[2] >> >>java.util.Arrays is used a fair bit for String handling >>(java.lang.StringCoding, java.langStringLatin1, etc).? The problem is >>that early in startup, depending on the locale/language setup and/or >>property settings, java.util.Arrays can be called during initialization >>of system properties. >> >>During Arrays., COMMON_PARALLELISM is setup with a call to >>ForkJoinPool.getCommonPoolParallelism().? ForkJoinPool sets up >>some VarHandles, VarHandles leads to >>MethodHandleStatics., which reads some system properties.? But >>we're still initializing the system properties - 'props' is null, so NPE. > >Chicken-egg problem. Maybe this field could be wrapped in a getter doing lazy resolution... >> >>I think Arrays.java needs to remove the COMMON_PARALLELISM constant, and >>go back to making calls to ForkJoinPool.getCommonPoolParallelism(). > >I do not know why Vladimir changed that recently. Any good reason ? >> >>I can do the update and post an updated webrev (unless further >>discussion is needed). Yes, please, remove?COMMON_PARALLELISM constant and replace by call ForkJoinPool.getCommonPoolParallelism(). in parallelSort() methods. Please, go ahead and update webrev with corrected Arrays.java >> >PS: I can help on benchmarking as I developed a fair sort benchmark based on JMH: >https://github.com/bourgesl/nearly-optimal-mergesort-code > >JMH test code: >https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/src/main/java/edu/sorting/bench >I would be interested by improving the perf test code and possibly integrate it in OpenJDK JMH test suite... (later) > >Goodbye & good luck, >Laurent -- Vladimir Yaroslavskiy From adinn at redhat.com Thu Aug 1 09:49:08 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 1 Aug 2019 10:49:08 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>

Message-ID: <04ac9cb2-4d7b-d316-9031-b4ce68c3b58e@redhat.com> Hi Boris, On 31/07/2019 13:01, Boris Ulasevich wrote: > I did a quick check of the change across our platforms. Arm32 and x86_64 > built successfully. But I see it fails due to minor issues on aarch64 > and x86_32 with webrev.09. > Can you please have a look at this? > >> src/hotspot/cpu/aarch64/aarch64.ad:2202:1: error: expected ?;? before > ?}? token >> src/hotspot/cpu/x86/macroAssembler_x86.cpp:9925: undefined reference > to `Assembler::clflush(Address)' The AArch64 error was simply a missing semi-colon. With that corrected AArch64 now builds and runs as expected (i.e. it fails the PMem support test with an UnsupportedOperationException). The second error is happening because the calling method MacroAssembler::cache_wb has not been guarded with #ifdef _LP64 (the same applies for MacroAssembler::cache_wbsync). Note that cache line writeback via Unsafe.writeBackMemory is only expected to work on Intel x86_64 so these two methods only get called from x86_64-specific code (x86_64.ad and stuGenerator_x86_64.cpp). So, the solution to this specific problem is to add #ifdef _LP64 around the declaration and implementation of these two methods. At the same time it would be helpful to remove the redundant #ifdef _LP64/#endif that I for some strange reason inserted around the definitions, but not the declarations, of clflushopt and clwb (that didn't help when I was trying to work out what was going wrong). However, a related problem also needs fixing. The Java code for method Unsafe.writebackMemory only proceeds when the data cache line writeback unit size (value of field UnsafeConstants.DATA_CACHE_LINE_FLUSH_SIZE) is non-zero. Otherwise it throws an exception. On x86_32 that field /must/ be zero. The native methods which Unsafe calls out to and the intrinsics which replace the native calls are not implemented on x86_32. The field from which the value of the Java constant is derived is currently initialised using CPU-specific information in vm_version_x86.cpp as follows if (os::supports_map_sync()) { // publish data cache line flush size to generic field, otherwise // let if default to zero thereby disabling writeback _data_cache_line_flush_size = _cpuid_info.std_cpuid1_ebx.bits.clflush_size * 8; } i.e. writeback is enabled on x86 when the operating is known to be capable of supporting MAP_SYNC. os_linux.cpp returns true for that call, irrespective of whether this is 32 or 64 bit linux. The rationale is that any Linux is capable of supporting map_sync (by contrast Windows, Solaris, AIX etc currently return false). So, the above assignment also needs to be guarded by #ifdef _LP64 in order to ensure that writeback is never attempted on x86_32. Thank you for spotting these errors. I will add the relevant fixes to the next patch and add you as a reviewer. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thejasvi.v.voniadka at oracle.com Thu Aug 1 13:42:08 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Thu, 1 Aug 2019 06:42:08 -0700 (PDT) Subject: RFR: 8158880: test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale Message-ID: Hi, Request you to please review this change. JBS: https://bugs.openjdk.java.net/browse/JDK-8158880 (test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale) Description: The test " test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java# test_appendZoneText_parseGenericTimeZonePatterns" fails if run on certain locales (such as "ja"). At present the test does not enforce a specific locale for the DateTimeFormatter, and hence the machine's locale is used as the default. This could cause parsing mismatches when run on non-US locales. The fix is to set the locale explicitly in the test. Webrev: http://cr.openjdk.java.net/~vagarwal/8158880/webrev.0 From naoto.sato at oracle.com Thu Aug 1 16:13:19 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 1 Aug 2019 09:13:19 -0700 Subject: RFR: 8158880: test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale In-Reply-To: References: Message-ID: Looks good to me, Thejasvi. Naoto On 8/1/19 6:42 AM, Thejasvi Voniadka wrote: > Hi, > > Request you to please review this change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158880 (test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale) > > Description: The test " test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java# test_appendZoneText_parseGenericTimeZonePatterns" fails if run on certain locales (such as "ja"). At present the test does not enforce a specific locale for the DateTimeFormatter, and hence the machine's locale is used as the default. This could cause parsing mismatches when run on non-US locales. The fix is to set the locale explicitly in the test. > > Webrev: http://cr.openjdk.java.net/~vagarwal/8158880/webrev.0 > > > From naoto.sato at oracle.com Thu Aug 1 17:02:31 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 1 Aug 2019 10:02:31 -0700 Subject: RFR (XS) 8228352 : CANON_EQ breaks when pattern contains supplementary codepoint In-Reply-To: References: Message-ID: <0e4bd953-7435-120d-adfe-956fc3b837e4@oracle.com> Hi Ivan, The change looks good to me. Naoto On 7/31/19 9:21 PM, Ivan Gerasimov wrote: > Hello! > > Pattern.compile fails with IOOB when normalizing a pattern that contains > a surrogate pair. > > Would you please help review a trivial 1-line fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8228352 > WEBREV: http://cr.openjdk.java.net/~igerasim/8228352/00/webrev/ > From rafael.wth at gmail.com Thu Aug 1 18:42:32 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Thu, 1 Aug 2019 20:42:32 +0200 Subject: RFC 8228988: Handle annotation values with incompatible runtime type Message-ID: Hello, I tried to fix a bug in AnnotationParser that throws a NullPointerException if an annotation enum property was refactored to an enumeration type or vice versa but retained its old name. There is currently no check if an annotation property is consistent with the runtime type, only the existance of the type is validated which causes this null pointer. I struggled to write a test for Jtreg as this requires quite a lot of setup but I hope that it is quite straight-forward to see from the changed code segments that the validation is missing. Nevertheless, I am not sure if this is the exception that would be expected from such a scenario. Here is the diff file inlined: Index: src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java (revision 55752:8ae33203d600a7c9f9b2be9b31a0eb8197270ab1) +++ src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java (revision 55752+:8ae33203d600+) @@ -358,6 +358,9 @@ result = parseConst(tag, buf, constPool); } + if (result == null) + result = new AnnotationTypeMismatchExceptionProxy( + memberType.getClass().getName()); if (!(result instanceof ExceptionProxy) && !memberType.isInstance(result)) result = new AnnotationTypeMismatchExceptionProxy( @@ -470,7 +473,10 @@ int constNameIndex = buf.getShort() & 0xFFFF; String constName = constPool.getUTF8At(constNameIndex); - if (!typeName.endsWith(";")) { + if (!enumType.isEnum()) + return new AnnotationTypeMismatchExceptionProxy( + typeName + "." + constName); + else if (!typeName.endsWith(";")) { // support now-obsolete early jsr175-format class files. if (!enumType.getName().equals(typeName)) return new AnnotationTypeMismatchExceptionProxy( From roger.riggs at oracle.com Thu Aug 1 21:40:19 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 1 Aug 2019 14:40:19 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> References:

<83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> Message-ID: Hi Joe, It would be good to more closely define the semantics of the @Serial annotation. Suggestion for the first sentence: "@Serial annotates each field or method specified by the Java Object Serialization Specification of a {@linkplain Serializable serializable} class." This annotation type is intended to allow compile-time checking of serialization-related declarations, analogous to the checking enabled by the {@link java.lang.Override} annotation type to validate method overriding. It would be useful to describe that reflection is used to access and use the fields and methods and they may? otherwise appear to be unused. A recommendation could be added in an @impleNote to apply @Serial to each serialization defined method or field. $02, Roger On 7/13/19 1:16 PM, Joe Darcy wrote: > PS I've uploaded an updated an iteration of the webrev > > http://cr.openjdk.java.net/~darcy/8202385.4/ > > to address. the syntactic concerns previously raised. I added > > ??? ...defined by the? Java Object Serialization > Specification... > > which is the current name of the document and is similar to the style > of reference made in java.io.Serializable. Offhand, I didn't know of > the correct idiom to refer to the document as a working hyperlink, but > would be switch to that idiom. > > Cheers, > > -Joe > > On 7/12/2019 8:19 PM, Joe Darcy wrote: >> Hi Roger, >> >> On 7/12/2019 1:31 PM, Roger Riggs wrote: >>> Hi Joe, >>> >>> As an annotation on a field or method, this is a use site annotation. >> >> >> It is an annotation intended for the declarations of fields and >> methods of Serializable types. >> >> >>> From the description, the checks that could be added would only be done >>> if the annotation was present and the annotation is a tag for existing >>> fields and methods that are part of the serialization spec. >> >> >> Right; the annotation is semantically only applicable to the fields >> and methods associated with the serialization system. >> >> >>> >>> The signatures of the fields and methods can be known to the >>> compiler independent >>> of the annotation and produce the same warnings. >>> So this looks like a case of trying to have belt and suspenders. >>> >>> If the checks are not done when the annotation is not present, then >>> it will still be >>> the case that incorrect or misused fields and methods will still >>> escape detection. >>> >>> Though the details of the compiler check are outside of the scope of >>> this annotation, >>> it seems unclear whether the annotation is necessary. >> >> I have a prototype annotation processor to implement checks for >> >> ??? JDK-8202056: Expand serial warning to check for bad overloads of >> serial-related methods and ineffectual fields >> >> The current version of the processor does not assume the presence of >> java.io.Serial. The summarize the existing checking methodology: >> >> ??? If a type is Serialiazable and a field or method has a name >> matching the names of one of the special fields or methods to >> serialization, check that the field or method has the required >> modifiers, type, and, the the case of methods, parameter types and >> exception types. >> >> That is all well and good and represents a large fraction of the >> checking of interest. However, it does not catch a mis-declaration >> like "readobject" instead of "readObject". One could argue that >> sufficiently thorough testing should catch that kind of error; >> however, my impression is that thoroughness of testing is rare in >> practice. I don't think it would be reasonable for javac to have some >> kind of Hamming distance >> (https://en.wikipedia.org/wiki/Hamming_distance) check between the >> name of fields/methods and the name of the serialization related >> fields methods to try to catch such mis-declarations. An annotation >> like java.io.Serial is intended to allow the programmer to indicate >> "yes, this is supposed to be one of the serialization related fields >> or methods" and enable the compile to perform checks against that >> category of error. >> >> >>> >>> Can the name of the annotation be more descriptive? >>> Just "Serial" seems a bit too simple and does not have a strong >>> binding to the Serialization classes and specification. >>> Alternatives: >>> ?? SerialMetadata >>> ?? SerialControl >>> ?? SerialFunction >> >> From the earlier design iterations "Serial" was chosen to be >> evocative of the "@serial" javadoc tag. >> >> Thanks, >> >> -Joe >> >>> >>> >>> 39:? There should be a reference to the serialization specification >>> for the definition >>> of the fields and methods to make it clear where the authoritative >>> identification is spec'd. >>> >>> 73-75:? Please align the

and tags on separate lines with >>> matching indentation. >>> >>> 77: Extra leading space. >>> >>> Regards, Roger >>> >>> On 7/9/19 7:14 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Returning to some old work [1], please review the addition of a >>>> java.io.Serial annotation type for JDK 14 to mark serial-related >>>> fields and methods: >>>> >>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8202385.3/ >>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] Previous review threads: >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053055.html >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054801.html >>>> >>>> >>> From ivan.gerasimov at oracle.com Fri Aug 2 00:51:49 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 1 Aug 2019 17:51:49 -0700 Subject: RFR (XS) 8228352 : CANON_EQ breaks when pattern contains supplementary codepoint In-Reply-To: <0e4bd953-7435-120d-adfe-956fc3b837e4@oracle.com> References: <0e4bd953-7435-120d-adfe-956fc3b837e4@oracle.com> Message-ID: Thank you Naoto for the review! With kind regards, Ivan On 8/1/19 10:02 AM, naoto.sato at oracle.com wrote: > Hi Ivan, > > The change looks good to me. > > Naoto > > On 7/31/19 9:21 PM, Ivan Gerasimov wrote: >> Hello! >> >> Pattern.compile fails with IOOB when normalizing a pattern that >> contains a surrogate pair. >> >> Would you please help review a trivial 1-line fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8228352 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8228352/00/webrev/ >> > -- With kind regards, Ivan Gerasimov From joel.borggren.franck at gmail.com Fri Aug 2 08:00:41 2019 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Fri, 2 Aug 2019 10:00:41 +0200 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References:

Message-ID: Hi Rafael Thanks for looking into this. Can you separate the two fixes into two different patches? The tests should be moved to java/lang/annotation/typeAnnotations/... . Nit, copyright year is wrong. 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. cheers /Joel On Tue, Jul 23, 2019 at 8:51 PM Rafael Winterhalter wrote: > I integrated the tests into the jtreg bits (to me it looks like they are > running ok but since this is my first time, please double-check). > > I have already signed the OCA a few years ago when I did some work on > Glassfish. Let me know if anything else is missing or if I need to do > anything else. > > Here comes the inline changeset including the additional jtreg tests: > > Index: > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java > (revision 55752+:8ae33203d600+) > +++ > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java > (revision 55752+:8ae33203d600+) > @@ -0,0 +1,52 @@ > +/* > + * Copyright (c) 2005, 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 > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8202473 > + * @summary Make sure a type variable bound on a parameterized > non-interface bound does not receive a type path offset > + */ > + > +import java.lang.annotation.Target; > +import java.lang.annotation.*; > +import java.lang.reflect.AnnotatedType; > +import java.lang.reflect.TypeVariable; > +import java.util.ArrayList; > + > +public class TestTypeAnnotationParameterizedNonInterfaceBound @TestTypeAnnotationParameterizedNonInterfaceBound.TypeAnnotation > ArrayList> { > + > + public static void main(String[] args) { > + TypeVariable[] variables = > TestTypeAnnotationParameterizedNonInterfaceBound.class.getTypeParameters(); > + TypeVariable variable = variables[0]; > + AnnotatedType[] bounds = variable.getAnnotatedBounds(); > + AnnotatedType bound = bounds[0]; > + Annotation[] annotations = bound.getAnnotations(); > + if (annotations.length != 1) { > + throw new AssertionError(); > + } > + } > + > + @Retention(RetentionPolicy.RUNTIME) > + @Target(ElementType.TYPE_USE) > + @interface TypeAnnotation { } > +} > Index: > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java > (revision 55752+:8ae33203d600+) > +++ > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java > (revision 55752+:8ae33203d600+) > @@ -0,0 +1,61 @@ > +/* > + * Copyright (c) 2005, 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 > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8202473 > + * @summary Make sure a type path for a type variable's bound is filtered > by variable index > + */ > + > +import java.lang.annotation.Target; > +import java.lang.annotation.*; > +import java.lang.reflect.AnnotatedParameterizedType; > +import java.lang.reflect.AnnotatedType; > +import java.lang.reflect.TypeVariable; > +import java.util.concurrent.Callable; > + > +public class TestTypeAnnotationTwoVariables< > + U extends > Callable<@TestTypeAnnotationTwoVariables.TypeAnnotation(0) ?>, > + V extends > Callable<@TestTypeAnnotationTwoVariables.TypeAnnotation(1) ?>> { > + > + public static void main(String[] args) { > + TypeVariable[] variables = > TestTypeAnnotationTwoVariables.class.getTypeParameters(); > + for (int i = 0; i < 2; i++) { > + TypeVariable variable = variables[i]; > + AnnotatedType[] bounds = variable.getAnnotatedBounds(); > + AnnotatedType bound = bounds[0]; > + AnnotatedParameterizedType parameterizedType = > (AnnotatedParameterizedType) bound; > + AnnotatedType[] actualTypeArguments = > parameterizedType.getAnnotatedActualTypeArguments(); > + Annotation[] annotations = > actualTypeArguments[0].getAnnotations(); > + if (annotations.length != 1 || ((TypeAnnotation) > annotations[0]).value() != i) { > + throw new AssertionError(); > + } > + } > + } > + > + @Retention(RetentionPolicy.RUNTIME) > + @Target(ElementType.TYPE_USE) > + @interface TypeAnnotation { > + int value(); > + } > +} > Index: > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java > (revision 55752+:8ae33203d600+) > +++ > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java > (revision 55752+:8ae33203d600+) > @@ -0,0 +1,51 @@ > +/* > + * Copyright (c) 2005, 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 > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8202469 > + * @summary Make sure a type variable that has another type variable as > its bound receives the correct type annotation > + */ > + > +import java.lang.annotation.Target; > +import java.lang.annotation.*; > +import java.lang.reflect.AnnotatedType; > +import java.lang.reflect.TypeVariable; > + > +public class TestTypeAnnotationTypeVariableBound @TestTypeAnnotationTypeVariableBound.TypeAnnotation U> { > + > + public static void main(String[] args) { > + TypeVariable[] variables = > TestTypeAnnotationTypeVariableBound.class.getTypeParameters(); > + TypeVariable variable = variables[1]; > + AnnotatedType[] bounds = variable.getAnnotatedBounds(); > + AnnotatedType bound = bounds[0]; > + Annotation[] annotations = bound.getAnnotations(); > + if (annotations.length != 1) { > + throw new AssertionError(); > + } > + } > + > + @Retention(RetentionPolicy.RUNTIME) > + @Target(ElementType.TYPE_USE) > + @interface TypeAnnotation { } > +} > Index: > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java > (revision 55752+:8ae33203d600+) > +++ > > test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java > (revision 55752+:8ae33203d600+) > @@ -0,0 +1,64 @@ > +/* > + * Copyright (c) 2005, 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 > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8202473 > + * @summary Make sure that the union bounds of a type variable receive the > correct type annotations > + */ > + > +import java.lang.annotation.Target; > +import java.lang.annotation.*; > +import java.lang.reflect.AnnotatedParameterizedType; > +import java.lang.reflect.AnnotatedType; > +import java.lang.reflect.TypeVariable; > +import java.util.List; > +import java.util.concurrent.Callable; > + > +public class TestTypeAnnotationUnionBound< > + U extends Callable<@TestTypeAnnotationUnionBound.TypeAnnotation(0) > ?> & List<@TestTypeAnnotationUnionBound.TypeAnnotation(1) ?>> { > + > + public static void main(String[] args) { > + TypeVariable[] variables = > TestTypeAnnotationUnionBound.class.getTypeParameters(); > + TypeVariable variable = variables[0]; > + if (variable.getAnnotations().length > 0) { > + throw new AssertionError(); > + } > + AnnotatedType[] bounds = variable.getAnnotatedBounds(); > + for (int i = 0; i < 2; i++) { > + AnnotatedType bound = bounds[i]; > + AnnotatedParameterizedType parameterizedType = > (AnnotatedParameterizedType) bound; > + AnnotatedType[] actualTypeArguments = > parameterizedType.getAnnotatedActualTypeArguments(); > + Annotation[] annotations = > actualTypeArguments[0].getAnnotations(); > + if (annotations.length != 1 || ((TypeAnnotation) > annotations[0]).value() != i) { > + throw new AssertionError(); > + } > + } > + } > + > + @Retention(RetentionPolicy.RUNTIME) > + @Target(ElementType.TYPE_USE) > + @interface TypeAnnotation { > + int value(); > + } > +} > Index: > > src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- > > src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java > (revision 55752:8ae33203d600a7c9f9b2be9b31a0eb8197270ab1) > +++ > > src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java > (revision 55752+:8ae33203d600+) > @@ -276,11 +276,21 @@ > // index 1. > if (bounds.length > 0) { > Type b0 = bounds[0]; > - if (!(b0 instanceof Class)) { > - startIndex = 1; > - } else { > - Class c = (Class)b0; > - if (c.isInterface()) { > + if (!(b0 instanceof TypeVariable)) { > + if (b0 instanceof Class) { > + Class c = (Class) b0; > + if (c.isInterface()) { > + startIndex = 1; > + } > + } else if (b0 instanceof ParameterizedType) { > + ParameterizedType p = (ParameterizedType) b0; > + Type r = p.getRawType(); > + if (!(r instanceof Class)) { > + throw new AnnotationFormatError("Unexpected > raw type: " + r); > + } else if (((Class) r).isInterface()) { > + startIndex = 1; > + } > + } else { > startIndex = 1; > } > } > @@ -295,10 +305,11 @@ > l.add(t); > } > } > + TypeAnnotation[] annon = > l.toArray(EMPTY_TYPE_ANNOTATION_ARRAY); > res[i] = > AnnotatedTypeFactory.buildAnnotatedType(bounds[i], > AnnotatedTypeFactory.nestingForType(bounds[i], > loc), > - l.toArray(EMPTY_TYPE_ANNOTATION_ARRAY), > - candidates.toArray(EMPTY_TYPE_ANNOTATION_ARRAY), > + annon, > + annon, > (AnnotatedElement)decl); > } > return res; > From 2217232293 at qq.com Sun Aug 4 17:12:37 2019 From: 2217232293 at qq.com (=?gb18030?B?zrTAtNH0ueI=?=) Date: Mon, 5 Aug 2019 01:12:37 +0800 Subject: help to become a auther Message-ID: Hi, all. I wana to commit to Core Libraries module. And I found a bug in this module. But I don?t have a jdk account to create a issue at https://bugs.openjdk.java.net. I had send a OCA to oracle-ca_us at oracle.com, what do I need to do next? thanks very match. My Info UserName: lamber-ken E-mail : 2217232293 at qq.com Tel : +8619941866946 Regards, lamber-ken From christoph.langer at sap.com Mon Aug 5 08:23:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Aug 2019 08:23:16 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References:

<953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>

<62a26037-a991-dc31-a972-a82386f63b92@oracle.com> <9806f4b1-9b55-d1d8-4511-5db0ef6786a5@oracle.com> <33E52896-E491-4660-A932-46D5A270A63E@oracle.com>

<458d4ce8-d669-3117-908d-687dae2ad8d2@oracle.com> Message-ID: Hi, the changeset for the zipfs POSIX permissions support seems to be ready now. I've spent some iterations with Lance to finalize it, mainly some formal things and additions/cleanups to the test. I've got reviews now from both, Alan and Lance. So, that's the last call for review/feedback/objections from anybody else. If I don't get further feedback I'm going to push this within the next 2-3 days: http://cr.openjdk.java.net/~clanger/webrevs/8213031.17/ Thank you, Christoph From: Langer, Christoph Sent: Mittwoch, 5. Juni 2019 16:45 To: Alan Bateman ; Lance Andersen Cc: nio-dev ; Java Core Libs Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions Hi Lance, Alan, et al., as it seems we are getting close to CSR approval, the changeset should also be finally reviewed. Here is the most current version: http://cr.openjdk.java.net/~clanger/webrevs/8213031.14/ I have made some updates to ZipConstants as suggested by Lance in a private mail. Best regards Christoph From ramanand.patil at oracle.com Mon Aug 5 08:27:49 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 5 Aug 2019 01:27:49 -0700 (PDT) Subject: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b Message-ID: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> Hi all, Please review the patch for tzdata2019b integration into jdk project(jdk-14). Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 Summary: - This patch uses "vanguard" format tzdata from IANA (instead of rearguard format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this. - As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java. Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3]. - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id. - The patch has passed all the related testing including JCK. Notes: - As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST. - Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same. [1] https://bugs.openjdk.java.net/browse/JDK-8212970 [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html [3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498 Regards, Ramanand. From naoto.sato at oracle.com Mon Aug 5 19:54:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 5 Aug 2019 12:54:51 -0700 Subject: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> Message-ID: Hi Ramanand, Looks good to me. Glad that the number of files to review has decreased a lot :-) Naoto On 8/5/19 1:27 AM, Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019b integration into jdk project(jdk-14). > Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 > > Summary: > - This patch uses "vanguard" format tzdata from IANA (instead of rearguard format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this. > - As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java. > Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3]. > - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id. > - The patch has passed all the related testing including JCK. > > Notes: > - As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST. > - Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same. > > > [1] https://bugs.openjdk.java.net/browse/JDK-8212970 > [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html > [3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498 > > > Regards, > Ramanand. > From martinrb at google.com Mon Aug 5 20:27:26 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Aug 2019 13:27:26 -0700 Subject: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> Message-ID: Thanks for the update and redundancy removal. Looks good to me. What is the recommendation for older releases? Migrate to vanguard format by backporting recent changes or stay on rearguard forever? On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019b integration into jdk > project(jdk-14). > Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 > > Summary: > - This patch uses "vanguard" format tzdata from IANA (instead of > rearguard format), as the enhancement bug[1] is fixed now. Many thanks to > Naoto for this. > - As per the latest changes to Palestine zone rules, the > hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in > ZoneInfoFile.java. > Because of those checks > test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned > in the bug comment[3]. > - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set > ZoneDescriptor.daylight value to "false" for BET zone id. > - The patch has passed all the related testing including JCK. > > Notes: > - As per the mail from tzdata maintainers[2] there is a possibility that > Brazil might not abolish DST. > - Since the enhancement bug[1] is not fixed in update releases, jdk13u > will still use the rearguard format tzdata. A separate review request will > be sent for the same. > > > [1] https://bugs.openjdk.java.net/browse/JDK-8212970 > [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html > [3] > https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498 > > > Regards, > Ramanand. > From raffaello.giulietti at gmail.com Mon Aug 5 21:02:48 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 5 Aug 2019 23:02:48 +0200 Subject: Are classes generated by LambdaMetafactory special? Message-ID: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> Hello, experiment suggests that classes generated by java.lang.invoke.LambdaMetafactory are somewhat special: (1) getName() on the class returns a string of the form Xxx$$Lambda$nn/0xhhh where Xxx is a fully qualified class name (with periods '.' as package separators), nn is a decimal integer and hhh is a hex integer. What's the role of the slash '/' in the name? (2) An invocation of Class.forName() with that name fails. (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() with that class as an argument returns false. Is this intentional or is it a bug? Greetings Raffaello From mandy.chung at oracle.com Mon Aug 5 21:11:02 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 5 Aug 2019 14:11:02 -0700 Subject: Are classes generated by LambdaMetafactory special? In-Reply-To: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> References: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> Message-ID: <4e9a7ffa-33f9-a4e9-078f-a7c421d891f4@oracle.com> This is intentional.? The lambda proxy classes are defined as VM anonymous classes through a JDK internal API Unsafe::defineAnonymousClass.? These generated classes are JDK implementation details that are hidden for any class lookup and not modifiable by JVM TI agent. JDK-8171335 is the RFE to define a supported API to replace Unsafe VM anonymous class.? We have a prototype in the "nestmates" branch in valhalla repo [1]. Mandy [1] http://hg.openjdk.java.net/valhalla/valhalla/ On 8/5/19 2:02 PM, Raffaello Giulietti wrote: > Hello, > > experiment suggests that classes generated by > java.lang.invoke.LambdaMetafactory are somewhat special: > > (1) getName() on the class returns a string of the form > ??? Xxx$$Lambda$nn/0xhhh > where Xxx is a fully qualified class name (with periods '.' as package > separators), nn is a decimal integer and hhh is a hex integer. What's > the role of the slash '/' in the name? > > (2) An invocation of Class.forName() with that name fails. > > (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() > with that class as an argument returns false. > > Is this intentional or is it a bug? > > > Greetings > Raffaello From forax at univ-mlv.fr Mon Aug 5 21:34:21 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 5 Aug 2019 23:34:21 +0200 (CEST) Subject: Are classes generated by LambdaMetafactory special? In-Reply-To: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> References: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> Message-ID: <461209609.160829.1565040861664.JavaMail.zimbra@u-pem.fr> It is intentional and the implementation details are planned to change in the future (there are already some patches in the valhalla/nestmates branch). The slash in the name is because you can create several classes from the same bytecode by patching it at runtime, the number after the slash is for each patching. Unlike a classical class, the class is not stored by a classloader in order to be garbage collected sooner, hence you can not find it this Class.forName. Intrumentation of a lambda proxy tends to fail because there is no API to get the patched data and because the class name is not resolvable (see above) so the easier solution was to mark those classes as non-modifiable. This may change in the future. R?mi ----- Mail original ----- > De: "raffaello giulietti" > ?: "core-libs-dev" > Envoy?: Lundi 5 Ao?t 2019 23:02:48 > Objet: Are classes generated by LambdaMetafactory special? > Hello, > > experiment suggests that classes generated by > java.lang.invoke.LambdaMetafactory are somewhat special: > > (1) getName() on the class returns a string of the form > Xxx$$Lambda$nn/0xhhh > where Xxx is a fully qualified class name (with periods '.' as package > separators), nn is a decimal integer and hhh is a hex integer. What's > the role of the slash '/' in the name? > > (2) An invocation of Class.forName() with that name fails. > > (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() > with that class as an argument returns false. > > Is this intentional or is it a bug? > > > Greetings > Raffaello From brent.christian at oracle.com Mon Aug 5 21:43:46 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 5 Aug 2019 14:43:46 -0700 Subject: RFR: 8226297: Dual-pivot quicksort improvements Message-ID: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> Hi, Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort (seen earlier[1] on this alias). I will be sponsoring this change. I have a webrev against jdk-jdk here: http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/ (Note that I did a little re-ordering, and removed some superfluous spacing changes, in order to simplify the webrev. I've also included Vladimir's FailedFloat[2] test case.) Information about benchmarking the changes was posted[3] recently. An automated test run passes cleanly. Thanks! -Brent -- 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061363.html 2. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061513.html 3. http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061553.html From raffaello.giulietti at gmail.com Mon Aug 5 21:51:41 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 5 Aug 2019 23:51:41 +0200 Subject: Are classes generated by LambdaMetafactory special? In-Reply-To: <461209609.160829.1565040861664.JavaMail.zimbra@u-pem.fr> References: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> <461209609.160829.1565040861664.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks R?mi and Mandy. I still don't get the full rationale on why lambda classes should be treated so specially but at least I now understand the current behavior. Greetings Raffaello On 05/08/2019 23.34, Remi Forax wrote: > It is intentional and the implementation details are planned to change in the future > (there are already some patches in the valhalla/nestmates branch). > > The slash in the name is because you can create several classes from the same bytecode by patching it at runtime, > the number after the slash is for each patching. > > Unlike a classical class, the class is not stored by a classloader in order to be garbage collected sooner, hence you can not find it this Class.forName. > > Intrumentation of a lambda proxy tends to fail because there is no API to get the patched data and because the class name is not resolvable (see above) so the easier solution was to mark those classes as non-modifiable. This may change in the future. > > R?mi > > ----- Mail original ----- >> De: "raffaello giulietti" >> ?: "core-libs-dev" >> Envoy?: Lundi 5 Ao?t 2019 23:02:48 >> Objet: Are classes generated by LambdaMetafactory special? > >> Hello, >> >> experiment suggests that classes generated by >> java.lang.invoke.LambdaMetafactory are somewhat special: >> >> (1) getName() on the class returns a string of the form >> Xxx$$Lambda$nn/0xhhh >> where Xxx is a fully qualified class name (with periods '.' as package >> separators), nn is a decimal integer and hhh is a hex integer. What's >> the role of the slash '/' in the name? >> >> (2) An invocation of Class.forName() with that name fails. >> >> (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() >> with that class as an argument returns false. >> >> Is this intentional or is it a bug? >> >> >> Greetings >> Raffaello From mandy.chung at oracle.com Tue Aug 6 00:04:47 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 5 Aug 2019 17:04:47 -0700 Subject: Are classes generated by LambdaMetafactory special? In-Reply-To: References: <65441a43-5705-1af0-0eff-610e534e477c@gmail.com> <461209609.160829.1565040861664.JavaMail.zimbra@u-pem.fr> Message-ID: <73bfb9b0-c53c-92fe-ad33-1f6a232ac868@oracle.com> One property of a lambda proxy class is to be in the same nest as the caller class as it's logically part of the caller class (as it may access its private member).? VM anonymous class is an interim implementation solution until we provide a way to define a dynamically generated class as a nestmate of an existing class. Second property of proxy classes is that proxy classes are not symbolically referenced by other class and they are sole implementation of some methods or some classes/interfaces.? Proxy classes can be defined as ordinary class while it has to ensure that the class name must be unique in the global VM namespace. There is overhead generating such a class to the system dictionary (not to mention loader constraints).? OTOH the name of a proxy class is only useful for troubleshooting but entirely not needed at runtime. Mandy On 8/5/19 2:51 PM, Raffaello Giulietti wrote: > Thanks R?mi and Mandy. > > I still don't get the full rationale on why lambda classes should be > treated so specially but at least I now understand the current behavior. > > > Greetings > Raffaello > > > > > On 05/08/2019 23.34, Remi Forax wrote: >> It is intentional and the implementation details are planned to >> change in the future >> (there are already some patches in the valhalla/nestmates branch). >> >> The slash in the name is because you can create several classes from >> the same bytecode by patching it at runtime, >> the number after the slash is for each patching. >> >> Unlike a classical class, the class is not stored by a classloader in >> order to be garbage collected sooner, hence you can not find it this >> Class.forName. >> >> Intrumentation of a lambda proxy tends to fail because there is no >> API to get the patched data and because the class name is not >> resolvable (see above) so the easier solution was to mark those >> classes as non-modifiable. This may change in the future. >> >> R?mi >> >> ----- Mail original ----- >>> De: "raffaello giulietti" >>> ?: "core-libs-dev" >>> Envoy?: Lundi 5 Ao?t 2019 23:02:48 >>> Objet: Are classes generated by LambdaMetafactory special? >> >>> Hello, >>> >>> experiment suggests that classes generated by >>> java.lang.invoke.LambdaMetafactory are somewhat special: >>> >>> (1) getName() on the class returns a string of the form >>> ???? Xxx$$Lambda$nn/0xhhh >>> where Xxx is a fully qualified class name (with periods '.' as package >>> separators), nn is a decimal integer and hhh is a hex integer. What's >>> the role of the slash '/' in the name? >>> >>> (2) An invocation of Class.forName() with that name fails. >>> >>> (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() >>> with that class as an argument returns false. >>> >>> Is this intentional or is it a bug? >>> >>> >>> Greetings >>> Raffaello From ramanand.patil at oracle.com Tue Aug 6 04:44:02 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 5 Aug 2019 21:44:02 -0700 (PDT) Subject: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: References: <0230ff0a-9f4b-4a59-b1e4-3eb76be23df9@default> Message-ID: Thank you Martin and Naoto for your reviews. Hi Martin, Currently, we are evaluating the approach for update releases. But in my opinion, it is better to migrate to vanguard format. Regards, Ramanand. From: Martin Buchholz Sent: Tuesday, August 6, 2019 1:57 AM To: Ramanand Patil Cc: core-libs-dev ; i18n-dev Subject: Re: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b Thanks for the update and redundancy removal.? Looks good to me. What is the recommendation for older releases?? Migrate to vanguard format by backporting recent changes or stay on rearguard forever? On Mon, Aug 5, 2019 at 1:28 AM Ramanand Patil wrote: Hi all, Please review the patch for tzdata2019b integration into jdk project(jdk-14). Webrev: http://cr.openjdk.java.net/~rpatil/8228469/14/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 Summary: ? ? ? ? - This patch uses "vanguard" format tzdata from IANA (instead of rearguard format), as the enhancement bug[1] is fixed now. Many thanks to Naoto for this. ? ? ? ? - As per the latest changes to Palestine zone rules, the hard-coded checks for "Asia/Gaza" and "Asia/Hebron" are no more needed in ZoneInfoFile.java. ? ? ? ? ? Because of those checks test/jdk/sun/util/calendar/zi/TestZoneInfo310.java was failing as mentioned in the bug comment[3]. ? ? ? ? - test/jdk/java/util/TimeZone/TimeZoneTest.java is updated to set ZoneDescriptor.daylight value to "false" for BET zone id. ? ? ? ? - The patch has passed all the related testing including JCK. Notes: - As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST. - Since the enhancement bug[1] is not fixed in update releases, jdk13u will still use the rearguard format tzdata. A separate review request will be sent for the same. [1] https://bugs.openjdk.java.net/browse/JDK-8212970 [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html [3] https://bugs.openjdk.java.net/browse/JDK-8228469?focusedCommentId=14281498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14281498 Regards, Ramanand. From ramanand.patil at oracle.com Tue Aug 6 05:57:47 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 5 Aug 2019 22:57:47 -0700 (PDT) Subject: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b Message-ID: Hi all, Please review the patch for jdk13u backport of tzdata2019b integration into jdk: Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 The patch is not clean because: It uses "rearguard" format tzdata from IANA (instead of vanguard format), as the enhancement bug[1] is not fixed in jdk13u. The patch has passed all the related testing including JCK. Note: As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST. [1] https://bugs.openjdk.java.net/browse/JDK-8212970 [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html Regards, Ramanand. From dl at cs.oswego.edu Tue Aug 6 11:28:03 2019 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 6 Aug 2019 07:28:03 -0400 Subject: Bug in parallel sorting of float / double In-Reply-To: <004c5e3c-f0f4-172c-6718-bc85667a2b24@oracle.com> References: <1563965581.761373630@f352.i.mail.ru> <1563973099.30911139@f507.i.mail.ru> <004c5e3c-f0f4-172c-6718-bc85667a2b24@oracle.com> Message-ID: <68f00e34-3d90-ad83-5e5d-93caed29b4ec@cs.oswego.edu> It's too bad that floating-point ordering issues that apparently no one cares about (no reports) limit performance, but the solution seems OK. Also: I've been reviewing drafts of this update for a year. They seem OK. (Although they are very much focused on details of existing primitive types; most likely a different approach will work better with value/inline types.) -Doug On 7/24/19 9:15 AM, David Holmes wrote: > Hi Vladimir, > > On 24/07/2019 10:58 pm, Vladimir Yaroslavskiy wrote: >> Hi?David, >> >> Please, see how it works: Arrays.parallelSort(double[]) >> invokes?ArraysParallelSortHelpers.FJDouble.Sorter >> if size is big enough and?ForkJoinPool.getCommonPoolParallelism()) > 1. >> >> FJDouble.Sorter divides given array into 4 parts, sorts them >> recursively in parallel and merges these parts. >> Finally?DualPivotQuicksort is invoked on small parts and only on this >> step NaNs and -0.0s are arranged. >> In other words,?NaNs and -0.0s are?arranged inside each small parts, >> but this action must be >> done once before the first splitting of the array. > > My understanding** was that the merge of the correctly sorted sub-arrays > would correctly cause NaNs to bubble to the end as required, while > zeroes would also group - though I think I can see now that simply using > < would not correctly order NaNs relative to other values, nor order > -0.0 and +0.0 > > ** It's been 7 years since I helped Doug Lea put the parallelising code > into the JDK so I'm a bit rusty on the details :) and I'm surprised such > a bug has not been detected before now. > > Cheers, > David > >> Thank you, >> Vladimir >> >> ??? ?????, 24 ???? 2019, 15:39 +03:00 ?? David Holmes >> ??? : >> >> ??? Hi Vladimir, >> >> ??? On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote: >> ???? > Hi all, >> ???? > >> ???? > I've found bug in parallel sorting of float / double arrays in >> ??? the latest JDK. >> ???? > >> ???? > When float / double values are sorted, additional actions are >> ???? > required: NaNs must be moved to the end and negative zeros >> ???? > must be placed before positive zeros. >> ???? > >> ???? > Current implementation of Arrays.parallelSort(float[] / double []) >> ???? > invokes parallel merge sort from ArraysParallelSortHelpers class, >> ???? > but it doesn't arrange NaNs and -0.0. >> >> ??? It ultimately uses DualPivotQuicksort which AFAICS does have code to >> ??? arrange NaNS: >> >> ???? ?????static void sort(float[] a, int left, int right, >> ???? ??????????????????????float[] work, int workBase, int workLen) { >> ???? ?????????/* >> ???? ??????????* Phase 1: Move NaNs to the end of the array. >> ???? ??????????*/ >> ???? ?????????while (left <= right && Float.isNaN(a[right])) { >> ???? ?????????????--right; >> ???? ?????????} >> >> ??? and also order +/-0 >> >> ???? ??????/* >> ???? ???????* Phase 3: Place negative zeros before positive zeros. >> ???? ???????*/ >> >> ??? where does the bug arise? >> >> ??? Thanks, >> ??? David >> ??? ----- >> >> >> ???? > @Alan, Brent, Laurent >> ???? > Could you please file a bug? >> ???? > >> ???? > New optimized version of DualPivotQuicksort (which is under >> ??? review) works fine and >> ???? > doesn't contain this bug. Please, look at my test case to >> ??? reproduce it. >> ???? > >> ???? > >> ??? >> ---------------------------------------------------------------------------------------------------------------------- >> >> ???? > import java.util.Random; >> ???? > >> ???? > public class FailedFloat { >> ???? > >> ???? > private static final int MAX_N = (1 << 13) /* >> ??? Arrays.MIN_ARRAY_SORT_GRAN */ + 10; >> ???? > >> ???? > public static void main(String[] args) { >> ???? > float[] a = new float[MAX_N]; >> ???? > random(a); >> ???? > java.util.Arrays.parallelSort(a); >> ???? > check(a); >> ???? > System.out.println("PASSED"); >> ???? > } >> ???? > >> ???? > private static void random(float[] a) { >> ???? > Random random = new Random(777); >> ???? > for (int i = 0; i < MAX_N; i++) { >> ???? > a[i] = random.nextBoolean() ? -0.0f : 0.0f; >> ???? > } >> ???? > } >> ???? > >> ???? > private static void check(float[] a) { >> ???? > for (int i = 0; i < a.length - 1; ++i) { >> ???? > if (Float.floatToRawIntBits(a[i]) == 0 && >> ??? Float.floatToRawIntBits(a[i + 1]) < 0) { >> ???? > throw new RuntimeException(a[i] + " goes before "+ a[i + 1] + " >> ??? at position " + i); >> ???? > } >> ???? > } >> ???? > } >> ???? > } >> ???? > >> ??? >> ------------------------------------------------------------------------------------------------------------------------ >> >> ???? > Thank you, >> ???? > Vladimir >> > From adinn at redhat.com Tue Aug 6 12:12:48 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 6 Aug 2019 13:12:48 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>

<36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com> Message-ID: Hi Aleksey/Boris, This is a response to both your last review posts. New webrev link is at the end. On 01/08/2019 12:16, Aleksey Shipilev wrote: > On 7/31/19 12:55 PM, Andrew Dinn wrote: . . . > I am more concerned that the writeback call enters the pre sync stub unnecessarily. The stub? I hope you mean when executing the native call as opposed to the JITted intrinsic? The stub is only called on a cold path when a native call proper happens. By contrast, the intrinsic translation for CacheWBPreSync on AArch64 and x86_64 does not insert any instructions into the generated code (and most especially not a call to the stub). Here it is: instruct cacheWBPreSync() %{ predicate(VM_Version::supports_data_cache_line_flush()); match(CacheWBPreSync); ins_cost(100); format %{"cache wb presync" %} ins_encode %{ __ cache_wbsync(true); %} ins_pipe(pipe_slow); // XXX %} void MacroAssembler::cache_wbsync(bool is_pre) { assert(VM_Version::supports_clflush(), "clflush should be available"); bool optimized = VM_Version::supports_clflushopt(); bool no_evict = VM_Version::supports_clwb(); // pick the correct implementation if (!is_pre && (optimized || no_evict)) { // need an sfence for post flush when using clflushopt or clwb // otherwise no no need for any synchroniaztion sfence(); } } > I had the idea to do this more efficiently, and simplify code at the same time: how about emitting > CacheWBPreSync nodes, but emitting nothing for them in .ad matchers? That would leave generic code > generic, and architectures would then be able to avoid the stub altogether for pre sync code. This > would simplify current stub generators too, I think: you don't need to pass arguments to them. I believe the intrinsic behaviour you are asking for is effectively what is implemented (as shown above). The .ad match rules for the PreSync and PostSync nodes both call MacroAssembler::cache_wbsync. For pre-sync it emits nothing. For post-sync it emits sfence when the writeback is implemented using clwb or clflushopt and nothing if writeback relies on clflush. > This leaves calling via Unsafe. I believe pulling up the isPre choice to the stub generation time > would be beneficial. That is, generate *two* stubs: StubRoutines::data_cache_writeback_pre_sync() > and StubRoutines::data_cache_writeback_post_sync(). If arch does not need the pre_sync, generate nop > version of pre_sync(). I don't really see any point to doing this. We can generate two stubs, one executing a nop and one executing a nop/sfence according to need. Or we can have one stub with a branch on the sync type and branch targets that execute either a nop or a nop/sfence as needed. The difference in performance of the stub is minor and irrelevant. The difference in generation time and memory use is minor and irrelevant. What are you trying to gain here? > This is not a strong requirement from my side. I do believe it would make code a bit more > straight-forward. Am I missing something here? Or did you simply miss that the intrinsic translation inserts no code for the presync? >>> === src/hotspot/cpu/x86/assembler_x86.cpp >>> >>> It feels like these comments are redundant, especially L8630 and L8646 which mention magic values >>> "6" and "7", not present in the code: > > ... > >> 8624 // 0x66 is instruction prefix >> >> 8627 // 0x0f 0xAE is opcode family >> >> 8630 // rdi == 7 is extended opcode byte >> . . . >> >> Given that the code is simply stuffing numbers (whether supplied as >> literals or as symbolic constants) into a byte stream I think these >> comments are a help when it comes to cross-checking each specific >> assembly against the corresponding numbers declared in the Intel >> manuals. So, I don't really want to remove them. Would you prefer me to >> reverse the wording as above? > > I was merely commenting on the style: the rest of the file does not have comments like that. The > positions of prefixes, opcode families, etc is kinda implied by the code shape. Yes, I too noticed that the rest of the file does not have any such comments :-] Given the highly variable shape of x86 machine code, I don't see any reason not to start remedying that omission, even if the remedy is only piecemeal. Commenting may not be a great help to maintainers who know the code and ISA really well but they are not the only audience. Even in that specific case the comments provide a sanity check. >>> === src/hotspot/cpu/x86/macroAssembler_x86.cpp >> // prefer clwb (potentially parallel writeback without evict) >> // otherwise prefer clflushopt (potentially parallel writeback >> // with evict) >> // otherwise fallback on clflush (serial writeback with evict) >> >> In the second case the comment is redundant because the need for an >> sfence is covered by the existing comment inside the if: >> >> // need an sfence for post flush when using clflushopt or clwb >> // otherwise no no need for any synchroniaztion > > Yes, this would be good to add. Ok, done. >>> === src/hotspot/share/opto/c2compiler.cpp >>> >>> Why inject new cases here, instead of at the end of switch? Saves sudden "break": >>> >>> 578 break; >>> 579 case vmIntrinsics::_writeback0: >>> 580 if (!Matcher::match_rule_supported(Op_CacheWB)) return false; >>> 581 break; >>> 582 case vmIntrinsics::_writebackPreSync0: >>> 583 if (!Matcher::match_rule_supported(Op_CacheWBPreSync)) return false; >>> 584 break; >>> 585 case vmIntrinsics::_writebackPostSync0: >>> 586 if (!Matcher::match_rule_supported(Op_CacheWBPostSync)) return false; >>> 587 break; >> >> I placed them here so they were close to the other Unsafe intrinsics. In >> particular they precede _allocateInstance, an ordering which is also the >> case in the declarations in vmSymbols.hpp. >> >> In what sense do you mean that an extra 'break' is saved? That would be >> true as regards the textual layout. It wouldn't affect the logic of >> folding different ranges of values into branching range tests (which is >> only determined by the numeric values of the intrinsics). If you are >> concerned about the former then I would argue that placing the values in >> declaration order seems to me to be the more important concern. > > I don't think we have to follow whatever ordering mess in vmSymbols.hpp. New code cuts into the last > case block in that switch, which is mostly about "we know about these symbols, they are > falling-through to the break". Adding cases with Matcher::match_rule_supported seems odd there. If > anything, those new cases should be moved upwards to other cases, e.g. after vmIntrinsics::_minD. As you wish. I have moved them to immediately preceding the large unbroken block. >>> === src/hotspot/share/prims/unsafe.cpp >>> >>> Do we really need this function pointer mess? >>> >>> 457 void (*wb)(void *); >>> 458 void *a = addr_from_java(line); >>> 459 wb = (void (*)(void *)) StubRoutines::data_cache_writeback(); >>> 460 assert(wb != NULL, "generate writeback stub!"); >>> 461 (*wb)(a); >>> >>> Seems easier to: >>> >>> assert(StubRoutines::data_cache_writeback() != NULL, "sanity"); >>> StubRoutines::data_cache_writeback()(addr_from_java(line)); >> Hmm, "that whole brevity thing" again? Well, I guess you must now call >> me "El Duderino". > > Well, that is, like, your opinion, man. C++ is messy if we allow it to be! > >> Are you sure that all the compilers used to build openJDK will happily >> eat the second line of your replacement? If you can guarantee that I'll >> happily remove the type declarations. > > I think they do: there are uses like that in the same file already, for example: > > if (StubRoutines::unsafe_arraycopy() != NULL) { > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz); > } else { > Copy::conjoint_memory_atomic(src, dst, sz); > } Hmm, your suggested replacement does not in fact compile. Indeed, the example you cite is comparing apples with pears -- note that the getter employed in call differs from the getter employed in the check. The following macro magic is provided for that example in stubRoutines.hpp: static address unsafe_arraycopy() { return _unsafe_arraycopy; } typedef void (*UnsafeArrayCopyStub)(const void* src, void* dst, size_t count); static UnsafeArrayCopyStub UnsafeArrayCopy_stub() { return CAST_TO_FN_PTR(UnsafeArrayCopyStub, _unsafe_arraycopy); } I have provided similar magic to hide the function pointer details for the writeback and writeback_sync stubs. Latest webrev against current jdk/jdk including changes agreed for the review discussion above fixes for AArch64/x86_32 build issues reported by Boris Ulasevich the new test promised for Boris Ulasevich http://cr.openjdk.java.net/~adinn/8224974/webrev.11 Testing: The x86_32 and aarch64 builds now build and run ok. The pmem-specific tests (PmemTest, MapFail) pass with the expected outcomes on x86_64 and AArch64. PmemTest is skipped on x86_32 (as expected). MapFail passes on x86_32 (it expects the map to be unsupported). I have passed the patch on for more thorough testing on simulated and real NVRAM using our middleware stack. I am still waiting for confirmation of a submit job. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Tue Aug 6 12:44:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 6 Aug 2019 14:44:19 +0200 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com> Message-ID: On 8/6/19 2:12 PM, Andrew Dinn wrote: > On 01/08/2019 12:16, Aleksey Shipilev wrote: >> On 7/31/19 12:55 PM, Andrew Dinn wrote: >> I am more concerned that the writeback call enters the pre sync stub unnecessarily. > > The stub? I hope you mean when executing the native call as opposed to > the JITted intrinsic? The stub is only called on a cold path when a > native call proper happens. By contrast, the intrinsic translation for > CacheWBPreSync on AArch64 and x86_64 does not insert any instructions > into the generated code (and most especially not a call to the stub). Ah, that is exactly what I wanted. Good then, scratch the rest of my comments. >> This is not a strong requirement from my side. I do believe it would make code a bit more >> straight-forward. > > Am I missing something here? Or did you simply miss that the intrinsic > translation inserts no code for the presync? I thought that translating two separate (and statically bound) Unsafe calls, hooking them up to separate Unsafe leaf entries, and then suddenly going into a single StubRoutine call with dynamic argument that dispatches at runtime is a bit awkward. I would have expected it to end up with two separate StubRoutines as well. Again, I have no strong opinion about this. >>>> === src/hotspot/share/prims/unsafe.cpp >>>> >>>> Do we really need this function pointer mess? >>>> >>>> 457 void (*wb)(void *); >>>> 458 void *a = addr_from_java(line); >>>> 459 wb = (void (*)(void *)) StubRoutines::data_cache_writeback(); >>>> 460 assert(wb != NULL, "generate writeback stub!"); >>>> 461 (*wb)(a); >>>> >>>> Seems easier to: ... > static address unsafe_arraycopy() { return _unsafe_arraycopy; } > typedef void (*UnsafeArrayCopyStub)(const void* src, void* dst, size_t > count); > static UnsafeArrayCopyStub UnsafeArrayCopy_stub() { return > CAST_TO_FN_PTR(UnsafeArrayCopyStub, _unsafe_arraycopy); } > > I have provided similar magic to hide the function pointer details for > the writeback and writeback_sync stubs. Yes, this looks cleaner. The declarations can be a bit less crowded: static address data_cache_writeback() { return _data_cache_writeback; } static address data_cache_writeback_sync() { return _data_cache_writeback_sync; } typedef void (*DataCacheWritebackStub)(void *); static DataCacheWritebackStub DataCacheWriteback_stub() { return ... typedef void (*DataCacheWritebackSyncStub)(bool); static DataCacheWritebackSyncStub DataCacheWritebackSync_stub() { return ... > http://cr.openjdk.java.net/~adinn/8224974/webrev.11 Looks good. Minor nits (no need for another webrev): *) Not sure if the only copyright line change is needed in src/hotspot/cpu/aarch64/globals_aarch64.hpp. *) Indenting is a bit off at L109 in src/hotspot/cpu/aarch64/vm_version_aarch64.hpp: 108 static int cpu_revision() { return _revision; } 109 static bool supports_dcpop() { return _dcpop; } *) Excess new line added at the end of src/hotspot/os/bsd/os_bsd.cpp? *) Indenting is off in backslashes in src/hotspot/share/runtime/globals.hpp: 2444 \ 2445 develop(bool, TraceMemoryWriteback, false, \ 2446 "Trace memory writeback operations") \ 2447 \ *) Unnecessary newline at L827 in src/hotspot/share/runtime/os.hpp? 826 // support for mapping non-volatile memory using MAP_SYNC 827 828 static bool supports_map_sync(); *) These declarations are too dense in src/java.base/share/classes/jdk/internal/misc/Unsafe.java: 998 /** 999 * primitive operation forcing writeback of a single cache line. 1000 * 1001 * @param address 1002 * the start address of the cache line to be written back 1003 */ 1004 // native used to write back an individual cache line starting at 1005 // the supplied address 1006 @HotSpotIntrinsicCandidate 1007 private native void writeback0(long address); 1008 // native used to serialise writeback operations relative to 1009 // preceding memory writes 1010 @HotSpotIntrinsicCandidate 1011 private native void writebackPreSync0(); 1012 // native used to serialise writeback operations relative to 1013 // following memory writes 1014 @HotSpotIntrinsicCandidate 1015 private native void writebackPostSync0(); Suggestion: /** * Force write back an individual cache line. * * @param address * the start address of the cache line to be written back */ @HotSpotIntrinsicCandidate private native void writeback0(long address); /** * Serialize writeback operations relative to preceding memory writes. */ @HotSpotIntrinsicCandidate private native void writebackPreSync0(); /** * Serialize writeback operations relative to following memory writes. */ @HotSpotIntrinsicCandidate private native void writebackPostSync0(); -- Thanks, -Aleksey From bourges.laurent at gmail.com Tue Aug 6 13:32:35 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 6 Aug 2019 15:32:35 +0200 Subject: RFR: 8226297: Dual-pivot quicksort improvements In-Reply-To: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> Message-ID: Hi Brent, Thank you for sponsoring this patch. I tried to compare your webrev against my latest (diff patch files) but it gives me too many changes lines. Do you have another idea to see incremental changes only ? (anyway I can compare raw files) Thanks, Laurent Le lun. 5 ao?t 2019 ? 23:43, Brent Christian a ?crit : > Hi, > > Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort > (seen earlier[1] on this alias). I will be sponsoring this change. > > I have a webrev against jdk-jdk here: > http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/ > > (Note that I did a little re-ordering, and removed some superfluous > spacing changes, in order to simplify the webrev. I've also included > Vladimir's FailedFloat[2] test case.) > > Information about benchmarking the changes was posted[3] recently. > An automated test run passes cleanly. > > Thanks! > -Brent > -- > 1. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061363.html > > 2. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061513.html > > 3. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061553.html > From adinn at redhat.com Tue Aug 6 13:57:05 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 6 Aug 2019 14:57:05 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com>

Message-ID: <67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> On 06/08/2019 13:44, Aleksey Shipilev wrote: > Ah, that is exactly what I wanted. Good then, scratch the rest of my comments. > . . . > I thought that translating two separate (and statically bound) Unsafe calls, hooking them up to > separate Unsafe leaf entries, and then suddenly going into a single StubRoutine call with dynamic > argument that dispatches at runtime is a bit awkward. I would have expected it to end up with two > separate StubRoutines as well. Again, I have no strong opinion about this. Ok, thanks for clarifying. Inertia dictates I leave the stubs as is :-) > Yes, this looks cleaner. The declarations can be a bit less crowded: > > static address data_cache_writeback() { return _data_cache_writeback; } > static address data_cache_writeback_sync() { return _data_cache_writeback_sync; } > > typedef void (*DataCacheWritebackStub)(void *); > static DataCacheWritebackStub DataCacheWriteback_stub() { return ... > > typedef void (*DataCacheWritebackSyncStub)(bool); > static DataCacheWritebackSyncStub DataCacheWritebackSync_stub() { return ... > . . . >> http://cr.openjdk.java.net/~adinn/8224974/webrev.11 > > Looks good. Ok, I'll fold this and the other format errors you identified into the next patch. If I could please get a nod from Alan Bateman (and assuming I don't receive further comments from other reviewers) I'll push that next patch. Any more for any more ... ? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.chuyko at bell-sw.com Tue Aug 6 14:25:40 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 6 Aug 2019 17:25:40 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com>

<67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> Message-ID: Hi Andrew, One quick question about synchronization in unmappers. One of preliminary steps for Loom was to replace monitor usage by j.u.c locks for I/O to let fibers release carrier threads. For instance see JDK-8222774. Does it make sense to do the same in your new unmappers code? -Dmitry [1] https://bugs.openjdk.java.net/browse/JDK-8222774 On 8/6/19 4:57 PM, Andrew Dinn wrote: > On 06/08/2019 13:44, Aleksey Shipilev wrote: >> Ah, that is exactly what I wanted. Good then, scratch the rest of my comments. >> . . . >> I thought that translating two separate (and statically bound) Unsafe calls, hooking them up to >> separate Unsafe leaf entries, and then suddenly going into a single StubRoutine call with dynamic >> argument that dispatches at runtime is a bit awkward. I would have expected it to end up with two >> separate StubRoutines as well. Again, I have no strong opinion about this. > Ok, thanks for clarifying. Inertia dictates I leave the stubs as is :-) > >> Yes, this looks cleaner. The declarations can be a bit less crowded: >> >> static address data_cache_writeback() { return _data_cache_writeback; } >> static address data_cache_writeback_sync() { return _data_cache_writeback_sync; } >> >> typedef void (*DataCacheWritebackStub)(void *); >> static DataCacheWritebackStub DataCacheWriteback_stub() { return ... >> >> typedef void (*DataCacheWritebackSyncStub)(bool); >> static DataCacheWritebackSyncStub DataCacheWritebackSync_stub() { return ... >> . . . >>> http://cr.openjdk.java.net/~adinn/8224974/webrev.11 >> Looks good. > Ok, I'll fold this and the other format errors you identified into the > next patch. > > > If I could please get a nod from Alan Bateman (and assuming I don't > receive further comments from other reviewers) I'll push that next patch. > > Any more for any more ... ? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.chuyko at bell-sw.com Tue Aug 6 14:50:18 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 6 Aug 2019 17:50:18 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> Message-ID: <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> Hi Andrew, Thanks for previous detailed explanations, and great, there are now checks for exceptions in webrev.11. Let me add just a few comments about that. On 8/1/19 12:49 PM, Andrew Dinn wrote: > Hello Dmitry, > > On 01/08/2019 05:09, Dmitry Chuyko wrote: >> Just a small comment about the tests. As you can see, some of tests in >> jdk/java/nio/channels/FileChannel check various modes, arguments, and >> expected exceptions. E.g. see MapTest, Mode and Args. >> >> I noticed that in your changes for the new map mode there are new >> exceptions thrown in different situations. For example, when the >> required mode is not supported, or it does not fit. In particular, this >> should happen correctly on systems that do not support nvram. Have you >> considered the possibility of extending or adding tests for this behavior? > I agree that these failure cases need better test coverage and > automation. However, that is not to say they have not been tested. All > current success and failure cases can be exercised by the current mmap > test (PmemTest) if run in the correct circumstance. Unfortunately, > automatic testing is not straightforward. New Unsafe.writebackMemory()/checkWritebackMemory()/checkWritebackEnabled() @throws RuntimeException "if memory writeback is not supported...". There is no test that check this behavior of Unsafe class while it seems to be relatively simple as inner check actually operates with a constant value. New MapFail test succeeds if proper IOException or any UnsupportedOperationException was caught but it aren't those situations actually 2 different ones that require distinct checks? If you say that is the situation when results depend on Linux version, it makes sense at least to put a comment in the test because it's really not trivial. Can PmemTest check IOException with message "map with mode MAP_SYNC unsupported" as a part of expected behavior, not just showing a test failure? -Dmitry > > 1) On x86_64 where MAP_SYNC is supported test PMemTest includes > instructions to exercise a successful map from a real or emulated DAX > file system. It can also be used (and has been used) to exercise the > IOException failure path in the case where the file it tries to open > belongs to a non-DAX file system (see line 99). > > Note that testing for success or failure cannot be done automatically > using the test as it currently stands. Testing for a successful map > requires mounting a real or emulated DAX file system at a known mount > point and creating a writable dir to hold the mapped file. Testing for > the IOException failure requires either setting up an equivalent non-DAX > file system mount or editing the test to open the file in a non-DAX file > system dir like, say, /tmp. > > A new, separate test for the IOException failure could be automated on > x86_64 by trying to map a file located in /tmp (on the assumption that > /tmp is not mounted as a DAX file system). Of course, at present this > will only give the IOException result when MAP_SYNC is supported. Given > a suitably old Linux/x86_64, UnsupportedOperationException could also be > thrown. > > 2) On AArch64 where MAP_SYNC is not currently supported PmemTest clearly > cannot be used to exercise the success path. However, it can be used > (and has been used) to exercise the UnsupportedOperationException > failure path. > > A check for the UnsupportedOperationException failure could be automated > on AArch64 by a new test as described above. Of course, once MAP_SYNC > support arrives in a new Linux/AArch64 it would also become for > IOException to be thrown. > > So, to sum up, it would be possible to add a new, automatic test that > checks for one or other failure occurring. I am happy to add such a test > to the next webrev. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From sean.coffey at oracle.com Tue Aug 6 15:13:54 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 6 Aug 2019 16:13:54 +0100 Subject: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: References: Message-ID: Looks good Ramanand. regards, Sean. On 06/08/2019 06:57, Ramanand Patil wrote: > Hi all, > Please review the patch for jdk13u backport of tzdata2019b integration into jdk: > Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 > > The patch is not clean because: It uses "rearguard" format tzdata from IANA (instead of vanguard format), as the enhancement bug[1] is not fixed in jdk13u. > The patch has passed all the related testing including JCK. > > Note: As per the mail from tzdata maintainers[2] there is a possibility that Brazil might not abolish DST. > > > [1] https://bugs.openjdk.java.net/browse/JDK-8212970 > [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html > > > Regards, > Ramanand. From naoto.sato at oracle.com Tue Aug 6 15:55:11 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 6 Aug 2019 08:55:11 -0700 Subject: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: References:

Message-ID: <657b66b4-a2f8-0edc-4d7b-37daf6d6a2be@oracle.com> +1 Naoto On 8/6/19 8:13 AM, Se?n Coffey wrote: > Looks good Ramanand. > > regards, > Sean. > > On 06/08/2019 06:57, Ramanand Patil wrote: >> Hi all, >> Please review the patch for jdk13u backport of tzdata2019b integration >> into jdk: >> Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 >> >> The patch is not clean because: It uses "rearguard" format tzdata from >> IANA (instead of vanguard format), as the enhancement bug[1] is not >> fixed in jdk13u. >> The patch has passed all the related testing including JCK. >> >> Note: As per the mail from tzdata maintainers[2] there is a >> possibility that Brazil might not abolish DST. >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212970 >> [2] https://mm.icann.org/pipermail/tz/2019-July/028344.html >> >> >> Regards, >> Ramanand. From adinn at redhat.com Tue Aug 6 15:58:57 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 6 Aug 2019 16:58:57 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> Message-ID: <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com> Hello Dmitry, On 06/08/2019 15:50, Dmitry Chuyko wrote: > Thanks for previous detailed explanations, and great, there are now > checks for exceptions in webrev.11. Let me add just a few comments about > that. Sure, no problem. Thank you for looking at the patch. > New > Unsafe.writebackMemory()/checkWritebackMemory()/checkWritebackEnabled() > @throws RuntimeException "if memory writeback is not supported...". > There is no test that check this behavior of Unsafe class while it seems > to be relatively simple as inner check actually operates with a constant > value. No this behaviour is not currently tested. However, the only client at present will never exercise that path so it is not critical to test it now. I'd be happy to address testing of this behaviour as part of a follow-up JIRA issue if you would be so good as to raise it. I say that because I would very much like to get this functionality into a release to simplify more extensive testing by Red Hat's middleware teams. > New MapFail test succeeds if proper IOException or any > UnsupportedOperationException was caught but it aren't those situations > actually 2 different ones that require distinct checks? If you say that > is the situation when results depend on Linux version, it makes sense at > least to put a comment in the test because it's really not trivial. The documentation of the API under test makes it clear that both errors can occur and under what circumstances. However, a note in the test will certainly do no harm. I will insert one before checking in the patch. > Can PmemTest check IOException with message "map with mode MAP_SYNC > unsupported" as a part of expected behavior, not just showing a test > failure? I don't see any need for this now that MapFail has been provided. Wit that alterative in place for checking map failures on non-DAX file syetems PmemTest is now primarily intended to test behaviour with a DAX file system which it expects to have been set up in advance as described in the main comment. So, the scenario you describe is not really an intended usage and I woudl argue that a failure is the right way to signal that. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Aug 6 16:09:46 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 6 Aug 2019 17:09:46 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com>

<67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> Message-ID: <3fb6e11f-4c95-8d88-3144-0c46c455a5db@redhat.com> Hello Dmitry, On 06/08/2019 15:25, Dmitry Chuyko wrote: > One quick question about synchronization in unmappers. One of > preliminary steps for Loom was to replace monitor usage by j.u.c locks > for I/O to let fibers release carrier threads. For instance see > JDK-8222774. Does it make sense to do the same in your new unmappers code? > . . . > [1] https://bugs.openjdk.java.net/browse/JDK-8222774 The unmapper code is not strictly 'new' as regards its reliance on synchronization. It merely follows and repeats the pattern employed in the prior code that it has generalized (by splitting the original Unmapper into two distinct flavours of subclass). If this poses a problem for Loom then it is a separate issue form the one this JEP addresses. I think you should raise a new issue for that change (just as you would have had to do before this change). I am sure Alan Bateman will be happy to consider your proposal. Indeed, I would be happy to implement it given his approval -- or leave it to you to do so if you prefer. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From patrick.concannon at oracle.com Tue Aug 6 16:20:49 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Tue, 6 Aug 2019 17:20:49 +0100 Subject: [13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters Message-ID: Hi, Would it be possible to have my fix for JDK-8228971 reviewed? The is a trivial doc-only fix which removes redundant hyphens for parameter descriptions for the Locale API doc. The intent is to push this to JDK 13. Further information on this bug can be found here: https://bugs.openjdk.java.net/browse/JDK-8228971 Webrev for fix: http://cr.openjdk.java.net/~dfuchs/pconcann/8228971/webrevs/webrev.1/ Kind regards, Patrick From naoto.sato at oracle.com Tue Aug 6 16:24:21 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 6 Aug 2019 09:24:21 -0700 Subject: [13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters In-Reply-To: References: Message-ID: Hi Patrick, Looks fine to me. Thanks for fixing the doc. Naoto On 8/6/19 9:20 AM, Patrick Concannon wrote: > Hi, > > Would it be possible to have my fix for JDK-8228971 reviewed? > > The is a trivial doc-only fix which removes redundant hyphens for > parameter descriptions for the Locale API doc. The intent is to push > this to JDK 13. > > Further information on this bug can be found here: > https://bugs.openjdk.java.net/browse/JDK-8228971 > > Webrev for fix: > http://cr.openjdk.java.net/~dfuchs/pconcann/8228971/webrevs/webrev.1/ > > > Kind regards, > > Patrick > From lance.andersen at oracle.com Tue Aug 6 16:25:22 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 6 Aug 2019 12:25:22 -0400 Subject: [13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters In-Reply-To: References: Message-ID: HI Patrick, I think the change is fine. Not sure it is a must have for 13 but either way good to go > On Aug 6, 2019, at 12:20 PM, Patrick Concannon wrote: > > Hi, > > Would it be possible to have my fix for JDK-8228971 reviewed? > > The is a trivial doc-only fix which removes redundant hyphens for parameter descriptions for the Locale API doc. The intent is to push this to JDK 13. > > Further information on this bug can be found here: https://bugs.openjdk.java.net/browse/JDK-8228971 > > Webrev for fix: http://cr.openjdk.java.net/~dfuchs/pconcann/8228971/webrevs/webrev.1/ > > > Kind regards, > > Patrick > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brent.christian at oracle.com Tue Aug 6 18:34:53 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 6 Aug 2019 11:34:53 -0700 Subject: RFR: 8226297: Dual-pivot quicksort improvements In-Reply-To: References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> Message-ID: <64e3ebb1-095e-08c0-ffc1-125346e2c960@oracle.com> Hi, Laurent I'm not sure what exactly is causing the problem, but here's my hunch: In Vladimir's version of Arrays.java: MIN_ARRAY_SORT_GRAN NaturalOrder rangeCheck got moved around, but were unchanged. In the interest of keeping the change as simple as possible, I restored these to their original location, so they don't show up in my changes. That could confuse things when comparing diffs. One idea would be to restore those elements back in their original locations in your version, and re-generate your patch. I don't know if that would be less work than just comparing raw files. Alternatively, if it would be easiest for those familiar with the evolution of this fix to leave things where Vladimir had them, I can do that. Thanks, -Brent On 8/6/19 6:32 AM, Laurent Bourg?s wrote: > Hi Brent, > > Thank you for sponsoring this patch. > > I tried to compare your webrev against my latest (diff patch files) but > it gives me too many changes lines. > > Do you have another idea to see incremental changes only ? > (anyway I can compare raw files) > > Thanks, > Laurent > > Le lun. 5 ao?t 2019 ? 23:43, Brent Christian > a ?crit?: > > Hi, > > Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort > (seen earlier[1] on this alias).? I will be sponsoring this change. > > I have a webrev against jdk-jdk here: > http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/ > > (Note that I did a little re-ordering, and removed some superfluous > spacing changes, in order to simplify the webrev.? I've also included > Vladimir's FailedFloat[2] test case.) > > Information about benchmarking the changes was posted[3] recently. > An automated test run passes cleanly. > > Thanks! > -Brent > -- > 1. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061363.html > > 2. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061513.html > > 3. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061553.html > From raffaello.giulietti at gmail.com Tue Aug 6 19:07:39 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 6 Aug 2019 21:07:39 +0200 Subject: Are classes generated by LambdaMetafactory special? Message-ID: Hi Mandy, thanks for the deeper explanation: all this makes much sense. Greetings Raffaello >One property of a lambda proxy class is to be in the same nest as the >caller class as it's logically part of the caller class (as it may >access its private member). VM anonymous class is an interim >implementation solution until we provide a way to define a dynamically >generated class as a nestmate of an existing class. > >Second property of proxy classes is that proxy classes are not >symbolically referenced by other class and they are sole implementation >of some methods or some classes/interfaces. Proxy classes can be >defined as ordinary class while it has to ensure that the class name >must be unique in the global VM namespace. There is overhead generating >such a class to the system dictionary (not to mention loader >constraints). OTOH the name of a proxy class is only useful for >troubleshooting but entirely not needed at runtime. > >Mandy > >On 8/5/19 2:51 PM, Raffaello Giulietti wrote: >> Thanks R?mi and Mandy. >> >> I still don't get the full rationale on why lambda classes should be >> treated so specially but at least I now understand the current behavior. >> >> >> Greetings >> Raffaello >> >> >> >> >> On 05/08/2019 23.34, Remi Forax wrote: >>> It is intentional and the implementation details are planned to >>> change in the future >>> (there are already some patches in the valhalla/nestmates branch). >>> >>> The slash in the name is because you can create several classes from >>> the same bytecode by patching it at runtime, >>> the number after the slash is for each patching. >>> >>> Unlike a classical class, the class is not stored by a classloader in >>> order to be garbage collected sooner, hence you can not find it this >>> Class.forName. >>> >>> Intrumentation of a lambda proxy tends to fail because there is no >>> API to get the patched data and because the class name is not >>> resolvable (see above) so the easier solution was to mark those >>> classes as non-modifiable. This may change in the future. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "raffaello giulietti" >>>> ?: "core-libs-dev" >>>> Envoy?: Lundi 5 Ao?t 2019 23:02:48 >>>> Objet: Are classes generated by LambdaMetafactory special? >>> >>>> Hello, >>>> >>>> experiment suggests that classes generated by >>>> java.lang.invoke.LambdaMetafactory are somewhat special: >>>> >>>> (1) getName() on the class returns a string of the form >>>> Xxx$$Lambda$nn/0xhhh >>>> where Xxx is a fully qualified class name (with periods '.' as package >>>> separators), nn is a decimal integer and hhh is a hex integer. What's >>>> the role of the slash '/' in the name? >>>> >>>> (2) An invocation of Class.forName() with that name fails. >>>> >>>> (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass() >>>> with that class as an argument returns false. >>>> >>>> Is this intentional or is it a bug? >>>> >>>> >>>> Greetings >>>> Raffaello > > From vlv.spb.ru at mail.ru Tue Aug 6 19:47:29 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Tue, 06 Aug 2019 22:47:29 +0300 Subject: =?UTF-8?B?UmVbMl06IFJGUjogODIyNjI5NzogRHVhbC1waXZvdCBxdWlja3NvcnQgaW1w?= =?UTF-8?B?cm92ZW1lbnRz?= In-Reply-To: <64e3ebb1-095e-08c0-ffc1-125346e2c960@oracle.com> References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> <64e3ebb1-095e-08c0-ffc1-125346e2c960@oracle.com> Message-ID: <1565120849.689130733@f473.i.mail.ru> Hi Brent,, I moved Object sorting related stuff after primitives sorting methods to separate functionality logically. The order of methods in my version is: 1. primitives (sequential sorting) - int - long - byte - char - short - float - double 2. primitives (parallel sorting) - int - long - byte - char - short - float - double 3. Object sorting 4. Other methods Thank you, Vladimir >???????, 6 ??????? 2019, 21:35 +03:00 ?? Brent Christian : > >Hi, Laurent > >I'm not sure what exactly is causing the problem, but here's my hunch: > >In Vladimir's version of Arrays.java: >???MIN_ARRAY_SORT_GRAN >???NaturalOrder >???rangeCheck >got moved around, but were unchanged. > >In the interest of keeping the change as simple as possible, I restored >these to their original location, so they don't show up in my changes. >That could confuse things when comparing diffs. > >One idea would be to restore those elements back in their original >locations in your version, and re-generate your patch. I don't know if >that would be less work than just comparing raw files. > >Alternatively, if it would be easiest for those familiar with the >evolution of this fix to leave things where Vladimir had them, I can do >that. > >Thanks, >-Brent > >On 8/6/19 6:32 AM, Laurent Bourg?s wrote: >> Hi Brent, >> >> Thank you for sponsoring this patch. >> >> I tried to compare your webrev against my latest (diff patch files) but >> it gives me too many changes lines. >> >> Do you have another idea to see incremental changes only ? >> (anyway I can compare raw files) >> >> Thanks, >> Laurent >> >> Le lun. 5 ao?t 2019 ? 23:43, Brent Christian < brent.christian at oracle.com >> > a ?crit?: >> >> Hi, >> >> Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort >> (seen earlier[1] on this alias).? I will be sponsoring this change. >> >> I have a webrev against jdk-jdk here: >> http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/ >> >> (Note that I did a little re-ordering, and removed some superfluous >> spacing changes, in order to simplify the webrev.? I've also included >> Vladimir's FailedFloat[2] test case.) >> >> Information about benchmarking the changes was posted[3] recently. >> An automated test run passes cleanly. >> >> Thanks! >> -Brent >> -- >> 1. >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061363.html >> >> 2. >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061513.html >> >> 3. >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061553.html >> -- Vladimir Yaroslavskiy From joe.darcy at oracle.com Tue Aug 6 20:04:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 6 Aug 2019 13:04:38 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: References:

<83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> Message-ID: Hi Roger, Revised webev ??? http://cr.openjdk.java.net/~darcy/8202385.5/ Diff of last two versions below. To ease review, I elected not to reflow the paragraphs at this time to reduce the number of lines of differences between the two versions. Several platform annotation types start there javadoc with "Indicates..." so I kept that pattern. It is true the serialization-defined fields and methods are accessed reflectively and may not be otherwise accessed. That seems more relevant to emphasize in the serialization spec itself, but it may be helpful to note here so I added one as requested. Cheers, -Joe 31c31 ? * Indicates that an annotated field or method is part of the {@linkplain 37c37,40 ? * validate method overriding. {@code Serializable} classes are encouraged to >? * use @Serial annotations to help a compiler catch >? * mis-declared serialization-related fields and methods, >? * mis-declarations that my otherwise be difficult to detect. 39c42 Specifically, annotations of this type are intended to be --- >? *

Specifically, annotations of this type should be 59c62 ? * Compilers are encouraged to validate that a method or field marked with a 61c64,65 ? * methods or fields declared in a meaningful context and issue a warning >? * if that is not the case. 86a91,94 >? * >? * Note that serialization mechanism accesses its designated fields >? * and methods reflectively and those fields and methods may appear >? * otherwise unused in a {@code Serializable} class. On 8/1/2019 2:40 PM, Roger Riggs wrote: > Hi Joe, > > It would be good to more closely define the semantics of the @Serial > annotation. > > Suggestion for the first sentence: > > "@Serial annotates each field or method specified by the Java > Object Serialization Specification of a {@linkplain > Serializable serializable} class." > > This annotation type is intended to allow compile-time checking of > serialization-related declarations, analogous to the checking enabled > by the {@link java.lang.Override} annotation type to validate method > overriding. > > It would be useful to describe that reflection is used to access and > use the fields and methods and they may? otherwise appear to be unused. > > A recommendation could be added in an @impleNote to apply @Serial to > each serialization defined method or field. > > $02, Roger > > On 7/13/19 1:16 PM, Joe Darcy wrote: >> PS I've uploaded an updated an iteration of the webrev >> >> http://cr.openjdk.java.net/~darcy/8202385.4/ >> >> to address. the syntactic concerns previously raised. I added >> >> ??? ...defined by the? Java Object Serialization >> Specification... >> >> which is the current name of the document and is similar to the style >> of reference made in java.io.Serializable. Offhand, I didn't know of >> the correct idiom to refer to the document as a working hyperlink, >> but would be switch to that idiom. >> >> Cheers, >> >> -Joe >> >> On 7/12/2019 8:19 PM, Joe Darcy wrote: >>> Hi Roger, >>> >>> On 7/12/2019 1:31 PM, Roger Riggs wrote: >>>> Hi Joe, >>>> >>>> As an annotation on a field or method, this is a use site annotation. >>> >>> >>> It is an annotation intended for the declarations of fields and >>> methods of Serializable types. >>> >>> >>>> From the description, the checks that could be added would only be >>>> done >>>> if the annotation was present and the annotation is a tag for existing >>>> fields and methods that are part of the serialization spec. >>> >>> >>> Right; the annotation is semantically only applicable to the fields >>> and methods associated with the serialization system. >>> >>> >>>> >>>> The signatures of the fields and methods can be known to the >>>> compiler independent >>>> of the annotation and produce the same warnings. >>>> So this looks like a case of trying to have belt and suspenders. >>>> >>>> If the checks are not done when the annotation is not present, then >>>> it will still be >>>> the case that incorrect or misused fields and methods will still >>>> escape detection. >>>> >>>> Though the details of the compiler check are outside of the scope >>>> of this annotation, >>>> it seems unclear whether the annotation is necessary. >>> >>> I have a prototype annotation processor to implement checks for >>> >>> ??? JDK-8202056: Expand serial warning to check for bad overloads of >>> serial-related methods and ineffectual fields >>> >>> The current version of the processor does not assume the presence of >>> java.io.Serial. The summarize the existing checking methodology: >>> >>> ??? If a type is Serialiazable and a field or method has a name >>> matching the names of one of the special fields or methods to >>> serialization, check that the field or method has the required >>> modifiers, type, and, the the case of methods, parameter types and >>> exception types. >>> >>> That is all well and good and represents a large fraction of the >>> checking of interest. However, it does not catch a mis-declaration >>> like "readobject" instead of "readObject". One could argue that >>> sufficiently thorough testing should catch that kind of error; >>> however, my impression is that thoroughness of testing is rare in >>> practice. I don't think it would be reasonable for javac to have >>> some kind of Hamming distance >>> (https://en.wikipedia.org/wiki/Hamming_distance) check between the >>> name of fields/methods and the name of the serialization related >>> fields methods to try to catch such mis-declarations. An annotation >>> like java.io.Serial is intended to allow the programmer to indicate >>> "yes, this is supposed to be one of the serialization related fields >>> or methods" and enable the compile to perform checks against that >>> category of error. >>> >>> >>>> >>>> Can the name of the annotation be more descriptive? >>>> Just "Serial" seems a bit too simple and does not have a strong >>>> binding to the Serialization classes and specification. >>>> Alternatives: >>>> ?? SerialMetadata >>>> ?? SerialControl >>>> ?? SerialFunction >>> >>> From the earlier design iterations "Serial" was chosen to be >>> evocative of the "@serial" javadoc tag. >>> >>> Thanks, >>> >>> -Joe >>> >>>> >>>> >>>> 39:? There should be a reference to the serialization specification >>>> for the definition >>>> of the fields and methods to make it clear where the authoritative >>>> identification is spec'd. >>>> >>>> 73-75:? Please align the

and tags on separate lines with >>>> matching indentation. >>>> >>>> 77: Extra leading space. >>>> >>>> Regards, Roger >>>> >>>> On 7/9/19 7:14 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Returning to some old work [1], please review the addition of a >>>>> java.io.Serial annotation type for JDK 14 to mark serial-related >>>>> fields and methods: >>>>> >>>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8202385.3/ >>>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> [1] Previous review threads: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053055.html >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054801.html >>>>> >>>>> >>>> > From lance.andersen at oracle.com Tue Aug 6 20:31:41 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 6 Aug 2019 16:31:41 -0400 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries Message-ID: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Hi Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 , where ZipFile does not return the correct size from the CEN when the Zip64 Extended Information Extra Field is used to store the entry size The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html Mach5 jdk tier1-tier3 all pass Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brent.christian at oracle.com Tue Aug 6 23:33:13 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 6 Aug 2019 16:33:13 -0700 Subject: RFR: 8226297: Dual-pivot quicksort improvements In-Reply-To: <1565120849.689130733@f473.i.mail.ru> References: <0bb235c8-a39c-addb-485a-d10664b3653b@oracle.com> <64e3ebb1-095e-08c0-ffc1-125346e2c960@oracle.com> <1565120849.689130733@f473.i.mail.ru> Message-ID: On 8/6/19 12:47 PM, Vladimir Yaroslavskiy wrote: > > I moved Object sorting related stuff after primitives sorting methods > to separate functionality logically. Sure, fine to keep that all together. I can move that back: http://cr.openjdk.java.net/~bchristi/8226297/webrev04/ > The order of methods in my version is: > > 1. primitives (sequential sorting) > - int > - long > - byte > - char > - short > - float > - double The order for sequential sorting of primitives in Arrays.java checked into the JDK is: - int - long * short * char * byte - float - double It simplifies the webrev for reviewing to keep that ordering, so that's what I've done. Thanks, -Brent > ???????, 6 ??????? 2019, 21:35 +03:00 ?? Brent Christian > : > > Hi, Laurent > > I'm not sure what exactly is causing the problem, but here's my hunch: > > In Vladimir's version of Arrays.java: > ???MIN_ARRAY_SORT_GRAN > ???NaturalOrder > ???rangeCheck > got moved around, but were unchanged. > > In the interest of keeping the change as simple as possible, I restored > these to their original location, so they don't show up in my changes. > That could confuse things when comparing diffs. > > One idea would be to restore those elements back in their original > locations in your version, and re-generate your patch. I don't know if > that would be less work than just comparing raw files. > > Alternatively, if it would be easiest for those familiar with the > evolution of this fix to leave things where Vladimir had them, I can do > that. > > Thanks, > -Brent > > On 8/6/19 6:32 AM, Laurent Bourg?s wrote: > > Hi Brent, > > > > Thank you for sponsoring this patch. > > > > I tried to compare your webrev against my latest (diff patch > files) but > > it gives me too many changes lines. > > > > Do you have another idea to see incremental changes only ? > > (anyway I can compare raw files) > > > > Thanks, > > Laurent > > > > Le lun. 5 ao?t 2019 ? 23:43, Brent Christian > > > > a ?crit?: > > > > Hi, > > > > Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort > > (seen earlier[1] on this alias).? I will be sponsoring this change. > > > > I have a webrev against jdk-jdk here: > > http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/ > > > > (Note that I did a little re-ordering, and removed some superfluous > > spacing changes, in order to simplify the webrev.? I've also included > > Vladimir's FailedFloat[2] test case.) > > > > Information about benchmarking the changes was posted[3] recently. > > An automated test run passes cleanly. > > > > Thanks! > > -Brent > > -- > > 1. > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061363.html > > > > 2. > > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061513.html > > > > 3. > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061553.html > > > > > > -- > Vladimir Yaroslavskiy From dmitry.chuyko at bell-sw.com Wed Aug 7 09:31:27 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 12:31:27 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com> Message-ID: On 8/6/19 6:58 PM, Andrew Dinn wrote: > ...................... > No this behaviour is not currently tested. However, the only client at > present will never exercise that path so it is not critical to test it > now. I'd be happy to address testing of this behaviour as part of a > follow-up JIRA issue if you would be so good as to raise it. I say that > because I would very much like to get this functionality into a release > to simplify more extensive testing by Red Hat's middleware teams. It sounds reasonable, I'll create a tiny RFE after you push the JEP. > >> New MapFail test succeeds if proper IOException or any >> UnsupportedOperationException was caught but it aren't those situations >> actually 2 different ones that require distinct checks? If you say that >> is the situation when results depend on Linux version, it makes sense at >> least to put a comment in the test because it's really not trivial. > The documentation of the API under test makes it clear that both errors > can occur and under what circumstances. However, a note in the test will > certainly do no harm. I will insert one before checking in the patch. > >> Can PmemTest check IOException with message "map with mode MAP_SYNC >> unsupported" as a part of expected behavior, not just showing a test >> failure? > I don't see any need for this now that MapFail has been provided. Wit > that alterative in place for checking map failures on non-DAX file > syetems PmemTest is now primarily intended to test behaviour with a DAX > file system which it expects to have been set up in advance as described > in the main comment. So, the scenario you describe is not really an > intended usage and I woudl argue that a failure is the right way to > signal that. OK, finally got it, thank you. -Dmitry > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.chuyko at bell-sw.com Wed Aug 7 09:44:51 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 12:44:51 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <3fb6e11f-4c95-8d88-3144-0c46c455a5db@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com>

<67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> <3fb6e11f-4c95-8d88-3144-0c46c455a5db@redhat.com> Message-ID: <83466f7a-0436-940c-ca87-2a8b4a7c3e7d@bell-sw.com> On 8/6/19 7:09 PM, Andrew Dinn wrote: > Hello Dmitry, > > On 06/08/2019 15:25, Dmitry Chuyko wrote: >> One quick question about synchronization in unmappers. One of >> preliminary steps for Loom was to replace monitor usage by j.u.c locks >> for I/O to let fibers release carrier threads. For instance see >> JDK-8222774. Does it make sense to do the same in your new unmappers code? >> . . . >> [1] https://bugs.openjdk.java.net/browse/JDK-8222774 > The unmapper code is not strictly 'new' as regards its reliance on > synchronization. It merely follows and repeats the pattern employed in > the prior code that it has generalized (by splitting the original > Unmapper into two distinct flavours of subclass). > > If this poses a problem for Loom then it is a separate issue form the > one this JEP addresses. I think you should raise a new issue for that > change (just as you would have had to do before this change). I am sure > Alan Bateman will be happy to consider your proposal. Indeed, I would be > happy to implement it given his approval -- or leave it to you to do so > if you prefer. Agree, Loom has a long road to go. So I suppose such a change will be a part of larger work in sun.nio, and I or one of my colleagues will be happy to participate. Changes will probably be straightforward (e.g. JDK-8222882) but this synchronization is not covered by regression tests so I believe in this case you'll help to retry some of your ad-hoc testing or maybe some application tests you know about. -Dmitry > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Wed Aug 7 10:21:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Aug 2019 11:21:31 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <3fb6e11f-4c95-8d88-3144-0c46c455a5db@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <3a3f9422-f81d-8ee2-5c07-687f2abe18df@redhat.com>

<67c3888c-9058-9e5c-273e-7810b1c66e29@redhat.com> <3fb6e11f-4c95-8d88-3144-0c46c455a5db@redhat.com> Message-ID: On 06/08/2019 09:09, Andrew Dinn wrote: > : > The unmapper code is not strictly 'new' as regards its reliance on > synchronization. It merely follows and repeats the pattern employed in > the prior code that it has generalized (by splitting the original > Unmapper into two distinct flavours of subclass). > > If this poses a problem for Loom then it is a separate issue form the > one this JEP addresses. I think you should raise a new issue for that > change (just as you would have had to do before this change). I am sure > Alan Bateman will be happy to consider your proposal. Indeed, I would be > happy to implement it given his approval -- or leave it to you to do so > if you prefer. > I don't think we need to be concerned with any of this at this time. The unmapper is run by the reference handler thread. Also the synchronization here is for the counters so not the same thing as doing a blocking I/O operation while holding a monitor. At some point we'll examine all the file I/O operations as some of these are candidates for managed blockers, others are candidates for alternative implementations - there are bigger issues to resolve first and we've been trying to avoid carrying too many changes due to the complexity and effort needed to keep them in sync with the main line. -Alan From christoph.langer at sap.com Wed Aug 7 10:24:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Aug 2019 10:24:15 +0000 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Message-ID: Hi Lance, this looks good to me. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Dienstag, 6. August 2019 22:32 > To: core-libs-dev > Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries > > Hi > > Please review the fix for https://bugs.openjdk.java.net/browse/JDK- > 8226530 , where > ZipFile does not return the correct size from the CEN when the Zip64 > Extended Information Extra Field is used to store the entry size > > The webrev can be found at > http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html > > > Mach5 jdk tier1-tier3 all pass > > Best > Lance > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From shade at redhat.com Wed Aug 7 10:43:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Aug 2019 12:43:47 +0200 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Message-ID: On 8/6/19 10:31 PM, Lance Andersen wrote: > The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html Looks good to me. I spot-tested my test cases that used to fail, and they all pass with this patch. Thanks! -Aleksey From dmitry.chuyko at bell-sw.com Wed Aug 7 11:02:47 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 14:02:47 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com> Message-ID: Andrew, New code is buildable and new MapFail test passes on different platforms except it fails on linux i386: ----------System.err:(12/712)---------- java.lang.Exception: unexpected message for IOExceptionInvalid argument ??? at MapFail.main(MapFail.java:60) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ??? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??? at java.base/java.lang.reflect.Method.invoke(Method.java:565) ??? at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246) ??? at java.base/java.lang.Thread.run(Thread.java:830) First there is a problem with the test, and a minor test issue is it would be good to add ": " before actual unexpected message. -Dmitry On 8/7/19 12:31 PM, Dmitry Chuyko wrote: > On 8/6/19 6:58 PM, Andrew Dinn wrote: >> ...................... >> No this behaviour is not currently tested. However, the only client at >> present will never exercise that path so it is not critical to test it >> now. I'd be happy to address testing of this behaviour as part of a >> follow-up JIRA issue if you would be so good as to raise it. I say that >> because I would very much like to get this functionality into a release >> to simplify more extensive testing by Red Hat's middleware teams. > It sounds reasonable, I'll create a tiny RFE after you push the JEP. >> >>> New MapFail test succeeds if proper IOException or any >>> UnsupportedOperationException was caught but it aren't those situations >>> actually 2 different ones that require distinct checks? If you say that >>> is the situation when results depend on Linux version, it makes >>> sense at >>> least to put a comment in the test because it's really not trivial. >> The documentation of the API under test makes it clear that both errors >> can occur and under what circumstances. However, a note in the test will >> certainly do no harm. I will insert one before checking in the patch. >> >>> Can PmemTest check IOException with message "map with mode MAP_SYNC >>> unsupported" as a part of expected behavior, not just showing a test >>> failure? >> I don't see any need for this now that MapFail has been provided. Wit >> that alterative in place for checking map failures on non-DAX file >> syetems PmemTest is now primarily intended to test behaviour with a DAX >> file system which it expects to have been set up in advance as described >> in the main comment. So, the scenario you describe is not really an >> intended usage and I woudl argue that a failure is the right way to >> signal that. > > OK, finally got it, thank you. > > -Dmitry > >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.chuyko at bell-sw.com Wed Aug 7 12:04:28 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 15:04:28 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com>

Message-ID: On 8/7/19 2:02 PM, Dmitry Chuyko wrote: > Andrew, > > New code is buildable and new MapFail test passes on different > platforms except it fails on linux i386: Ah, that even was x86_64 (sorry, mixed up results from automated system). I'll try to reproduce it by hand to see if there are any additional details. -Dmitry > > ----------System.err:(12/712)---------- > java.lang.Exception: unexpected message for IOExceptionInvalid argument > ??? at MapFail.main(MapFail.java:60) > ??? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > ??? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ??? at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ??? at java.base/java.lang.reflect.Method.invoke(Method.java:565) > ??? at > com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246) > ??? at java.base/java.lang.Thread.run(Thread.java:830) > > First there is a problem with the test, > and a minor test issue is it would be good to add ": " before actual > unexpected message. > > -Dmitry > > On 8/7/19 12:31 PM, Dmitry Chuyko wrote: >> On 8/6/19 6:58 PM, Andrew Dinn wrote: >>> ...................... >>> No this behaviour is not currently tested. However, the only client at >>> present will never exercise that path so it is not critical to test it >>> now. I'd be happy to address testing of this behaviour as part of a >>> follow-up JIRA issue if you would be so good as to raise it. I say that >>> because I would very much like to get this functionality into a release >>> to simplify more extensive testing by Red Hat's middleware teams. >> It sounds reasonable, I'll create a tiny RFE after you push the JEP. >>> >>>> New MapFail test succeeds if proper IOException or any >>>> UnsupportedOperationException was caught but it aren't those >>>> situations >>>> actually 2 different ones that require distinct checks? If you say >>>> that >>>> is the situation when results depend on Linux version, it makes >>>> sense at >>>> least to put a comment in the test because it's really not trivial. >>> The documentation of the API under test makes it clear that both errors >>> can occur and under what circumstances. However, a note in the test >>> will >>> certainly do no harm. I will insert one before checking in the patch. >>> >>>> Can PmemTest check IOException with message "map with mode MAP_SYNC >>>> unsupported" as a part of expected behavior, not just showing a test >>>> failure? >>> I don't see any need for this now that MapFail has been provided. Wit >>> that alterative in place for checking map failures on non-DAX file >>> syetems PmemTest is now primarily intended to test behaviour with a DAX >>> file system which it expects to have been set up in advance as >>> described >>> in the main comment. So, the scenario you describe is not really an >>> intended usage and I woudl argue that a failure is the right way to >>> signal that. >> >> OK, finally got it, thank you. >> >> -Dmitry >> >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From pavel.rappo at oracle.com Wed Aug 7 12:47:40 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 7 Aug 2019 13:47:40 +0100 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection Message-ID: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com> Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8217606/webrev.00/ The original issue seems to be an unintended consequence of JDK-8059009 [1]. The proposed change is based on the private patch by Chris Yin. I skimmed through the history of the `com.sun.jndi.ldap.Connection.useable` flag which dates back to JDK-4532408 [2] - Maintains a flag, 'useable', to indicate whether underlying network connection is useable. A connection starts out useable and becomes unuseable when an IO error is encountered while reading from/writing to it. and I believe that this field is a good fit for what Chris has proposed. Not only does the proposed change fix the issue, it also introduces a reusable test component for mocking/stubbing/faking an LDAP server. Chris and myself took some time in our private correspondence to shape that component such that it would allow to refactor some of the existing LDAP tests, should we decide to do so. As far as mach5 is concerned, the change looks good. Thanks, -Pavel ------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8059009 [2] https://bugs.openjdk.java.net/browse/JDK-4532408 From adinn at redhat.com Wed Aug 7 13:29:33 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Aug 2019 14:29:33 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com>

Message-ID: <785b8ac5-b62f-4e7d-eb42-a1532cf43992@redhat.com> On 07/08/2019 13:04, Dmitry Chuyko wrote: > On 8/7/19 2:02 PM, Dmitry Chuyko wrote: >> Andrew, >> >> New code is buildable and new MapFail test passes on different >> platforms except it fails on linux i386: > > Ah, that even was x86_64 (sorry, mixed up results from automated > system). I'll try to reproduce it by hand to see if there are any > additional details. Whew! Thank goodness it is x86_64. You had me very worried when you said this was i386 :-) So, this is indeed a problem with the test. The internal detail message for the IOException will vary according to the Linux kernel release. If MAP_SYNC is not supported by the Linux kernel it will embed the message you saw. If it is supported the message will be the one the test checks for. I think the best thing is for the test not to bother checking for a specific message. The important thing is that we should get either IOException or UnsupportedOperationException. Checking for the message is not really necessary. I will remove this check from the test. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From lance.andersen at oracle.com Wed Aug 7 13:30:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Aug 2019 09:30:30 -0400 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com> References: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com> Message-ID: Hi Pavel, The change looks good. Nice job on the tests :-) > On Aug 7, 2019, at 8:47 AM, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8217606/webrev.00/ > > The original issue seems to be an unintended consequence of JDK-8059009 [1]. > The proposed change is based on the private patch by Chris Yin. I skimmed > through the history of the `com.sun.jndi.ldap.Connection.useable` flag which > dates back to JDK-4532408 [2] > > - Maintains a flag, 'useable', to indicate whether underlying network > connection is useable. A connection starts out useable and becomes > unuseable when an IO error is encountered while reading from/writing > to it. > > and I believe that this field is a good fit for what Chris has proposed. > > Not only does the proposed change fix the issue, it also introduces a reusable > test component for mocking/stubbing/faking an LDAP server. Chris and myself took > some time in our private correspondence to shape that component such that it > would allow to refactor some of the existing LDAP tests, should we decide to > do so. > > As far as mach5 is concerned, the change looks good. > > Thanks, > -Pavel > > ------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8059009 > [2] https://bugs.openjdk.java.net/browse/JDK-4532408 > 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 dmitry.chuyko at bell-sw.com Wed Aug 7 13:32:38 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 16:32:38 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com>

Message-ID: <432d6b0c-61ea-2f70-c1d8-e1d6bd89ce02@bell-sw.com> The test fails on some machines but does not fail on others, all 4.x kernels. The possible problem may be when build host and run host are different machines. This seems to be related to map0() implementation in FileChannelImpl.c in case MAP_SYNC and MAP_SHARED_VALIDATE are not defined (or defined). I also recommend to print original ioe stacktrace in the test. Adding such gives us useful information like this: java.io.IOException: Invalid argument at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062) at MapFail.main(MapFail.java:48) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) java.lang.Exception: unexpected message for IOExceptionInvalid argument at MapFail.main(MapFail.java:61) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.io.IOException: Invalid argument at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062) at MapFail.main(MapFail.java:48) ... 6 more -Dmitry On 8/7/19 3:04 PM, Dmitry Chuyko wrote: > On 8/7/19 2:02 PM, Dmitry Chuyko wrote: >> Andrew, >> >> New code is buildable and new MapFail test passes on different >> platforms except it fails on linux i386: > > Ah, that even was x86_64 (sorry, mixed up results from automated > system). I'll try to reproduce it by hand to see if there are any > additional details. > > -Dmitry > >> >> ----------System.err:(12/712)---------- >> java.lang.Exception: unexpected message for IOExceptionInvalid argument >> ??? at MapFail.main(MapFail.java:60) >> ??? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ??? at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> ??? at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ??? at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> ??? at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246) >> ??? at java.base/java.lang.Thread.run(Thread.java:830) >> >> First there is a problem with the test, >> and a minor test issue is it would be good to add ": " before actual >> unexpected message. >> >> -Dmitry >> >> On 8/7/19 12:31 PM, Dmitry Chuyko wrote: >>> On 8/6/19 6:58 PM, Andrew Dinn wrote: >>>> ...................... >>>> No this behaviour is not currently tested. However, the only client at >>>> present will never exercise that path so it is not critical to test it >>>> now. I'd be happy to address testing of this behaviour as part of a >>>> follow-up JIRA issue if you would be so good as to raise it. I say >>>> that >>>> because I would very much like to get this functionality into a >>>> release >>>> to simplify more extensive testing by Red Hat's middleware teams. >>> It sounds reasonable, I'll create a tiny RFE after you push the JEP. >>>> >>>>> New MapFail test succeeds if proper IOException or any >>>>> UnsupportedOperationException was caught but it aren't those >>>>> situations >>>>> actually 2 different ones that require distinct checks? If you say >>>>> that >>>>> is the situation when results depend on Linux version, it makes >>>>> sense at >>>>> least to put a comment in the test because it's really not trivial. >>>> The documentation of the API under test makes it clear that both >>>> errors >>>> can occur and under what circumstances. However, a note in the test >>>> will >>>> certainly do no harm. I will insert one before checking in the patch. >>>> >>>>> Can PmemTest check IOException with message "map with mode MAP_SYNC >>>>> unsupported" as a part of expected behavior, not just showing a test >>>>> failure? >>>> I don't see any need for this now that MapFail has been provided. Wit >>>> that alterative in place for checking map failures on non-DAX file >>>> syetems PmemTest is now primarily intended to test behaviour with a >>>> DAX >>>> file system which it expects to have been set up in advance as >>>> described >>>> in the main comment. So, the scenario you describe is not really an >>>> intended usage and I woudl argue that a failure is the right way to >>>> signal that. >>> >>> OK, finally got it, thank you. >>> >>> -Dmitry >>> >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Senior Principal Software Engineer >>>> Red Hat UK Ltd >>>> Registered in England and Wales under Company Registration No. >>>> 03798903 >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.chuyko at bell-sw.com Wed Aug 7 13:46:57 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Aug 2019 16:46:57 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <785b8ac5-b62f-4e7d-eb42-a1532cf43992@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com>

<785b8ac5-b62f-4e7d-eb42-a1532cf43992@redhat.com> Message-ID: On 8/7/19 4:29 PM, Andrew Dinn wrote: > On 07/08/2019 13:04, Dmitry Chuyko wrote: >> On 8/7/19 2:02 PM, Dmitry Chuyko wrote: >>> Andrew, >>> >>> New code is buildable and new MapFail test passes on different >>> platforms except it fails on linux i386: >> Ah, that even was x86_64 (sorry, mixed up results from automated >> system). I'll try to reproduce it by hand to see if there are any >> additional details. > Whew! Thank goodness it is x86_64. You had me very worried when you said > this was i386 :-) > > So, this is indeed a problem with the test. The internal detail message > for the IOException will vary according to the Linux kernel release. If > MAP_SYNC is not supported by the Linux kernel it will embed the message > you saw. If it is supported the message will be the one the test checks for. > > I think the best thing is for the test not to bother checking for a > specific message. The important thing is that we should get either > IOException or UnsupportedOperationException. Checking for the message > is not really necessary. I will remove this check from the test. Ok, it will reduce complexity and likely let the test pass while still checking the same thing. -Dmitry > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Aug 7 14:06:36 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Aug 2019 15:06:36 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <432d6b0c-61ea-2f70-c1d8-e1d6bd89ce02@bell-sw.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <023aa8d9-c0f7-9353-536e-3d1a91689cf3@bell-sw.com> <762feb23-763a-6240-4939-5dc663037a36@bell-sw.com> <7852c79b-0507-aefa-beb8-4cb10f874db3@redhat.com>

<432d6b0c-61ea-2f70-c1d8-e1d6bd89ce02@bell-sw.com> Message-ID: <766bf750-2582-76f0-82d6-caaf1534ffcc@redhat.com> On 07/08/2019 14:32, Dmitry Chuyko wrote: > The test fails on some machines but does not fail on others, all 4.x > kernels. The possible problem may be when build host and run host are > different machines. This seems to be related to map0() implementation in > FileChannelImpl.c in case MAP_SYNC and MAP_SHARED_VALIDATE are not > defined (or defined). Ah yes, I see what is goign on now. It makes sense that you are seeing IOException: "Invalid argument" when passing MAP_SYNC to mmap on a Linux kernel that does not support those flags. Whereas on a Linux kernel which does support those flags you would expect to see the result i got IOException: "Operation not supported". That's because mmap with MAP_SYNC is not an appropriate operation to request on a non-DAX file. n.b. these messages come out of the relevant errno value. The AArch64 code produces an UnsupportedOperationException because the map with MAP_SYNC is being rejected in the Java code. That happens because I am running on an ARMV8.1 processor which does not support cache writeback to memory (ARMv8.2 chips are not yet generally available). The same applies for i386. It produces UnsupportedOperationException because the map with MAP_SYNC is being rejected in the Java code. The test needs tweaking to remedy this bad result and explain better the expected results. I don't think there is actually any great merit checking for a specific error message in the IOException so I will remove that check. The test should always expect IOException from x86, always expect UnsupportedOperationException from i386 and allow for either from AArch64. I have folded those fixes into the next version. > I also recommend to print original ioe stacktrace in the test. Adding > such gives us useful information like this: I have already done this too :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Roger.Riggs at oracle.com Wed Aug 7 15:52:49 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 7 Aug 2019 11:52:49 -0400 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: References: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com> Message-ID: Hi, Nicely structured server framework, some details to cleanup. BaseLdapServer: 100: The new exception should have a message "Unexpected exception" or "server should no be running"... 158: Is printing the stack trace diagnostic or an error?, the exception is not rethrown and no message clarifying the context of the trace is printed. Stack traces should go to the log as well or instead of stderr. 103: plural? "accepting connection" -> "accepting connections" 109: "template method" doesn't describe the method well, the method is private and not overridable. ?? update the javadoc. 154: Handle connection should handle? Throwable and log and error with a printStackTrace. Since it is called in a Executor, otherwise unhandled exceptions will dissappear. 178:? logger() should be final. The subclass has no reason to override.? And it can be "public final". 238: isRunning should be synchronized(lock) to make sure each Thread sees the same value threads that update it in start() and close() LdapMessage: 90:? plural?? byte[] messages implies multiple messages, not just a buffer for a single message. 136: Why make a copy?? Is it expected to be modified?? Be clear in the javadoc about the copy. 230: can the same trick using BigInteger (line 124) be used to extract the length? 184:? hexToBin(ch) -> Character.digit(ch, 16); Reconnect: 54: there is no need for a stylized new Reconnect().run(). Just call a static method and keep the test simple. 105:? Tests that sleep are prone to intermittent failures on slow or delayed systems. It would be more reliable to countdown *after* the Connection was handled. As is, it might report success even if handleRequest failed for some reason. Since the test only needs to know that the connection is made, a CountDownLatch could be used. Await() with a large timeout would complete as soon as the connection was made and still catch the case where it never happened.? If there as some suspecion of too many connections that could be checked after the beforeConnectionHandled called countDown. Since new infra structure is being introduced, it should be considered to leverage TestNG testing facilities and Asserts? Regards, Roger On 8/7/19 9:30 AM, Lance Andersen wrote: > Hi Pavel, > > The change looks good. Nice job on the tests :-) > > >> On Aug 7, 2019, at 8:47 AM, Pavel Rappo wrote: >> >> Hello, >> >> Please review the following change: >> >> http://cr.openjdk.java.net/~prappo/8217606/webrev.00/ >> >> The original issue seems to be an unintended consequence of JDK-8059009 [1]. >> The proposed change is based on the private patch by Chris Yin. I skimmed >> through the history of the `com.sun.jndi.ldap.Connection.useable` flag which >> dates back to JDK-4532408 [2] >> >> - Maintains a flag, 'useable', to indicate whether underlying network >> connection is useable. A connection starts out useable and becomes >> unuseable when an IO error is encountered while reading from/writing >> to it. >> >> and I believe that this field is a good fit for what Chris has proposed. >> >> Not only does the proposed change fix the issue, it also introduces a reusable >> test component for mocking/stubbing/faking an LDAP server. Chris and myself took >> some time in our private correspondence to shape that component such that it >> would allow to refactor some of the existing LDAP tests, should we decide to >> do so. >> >> As far as mach5 is concerned, the change looks good. >> >> Thanks, >> -Pavel >> >> ------------------------------------------------------------------------------- >> [1] https://bugs.openjdk.java.net/browse/JDK-8059009 >> [2] https://bugs.openjdk.java.net/browse/JDK-4532408 >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From brian.burkhalter at oracle.com Wed Aug 7 16:21:01 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Aug 2019 09:21:01 -0700 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Message-ID: <78C1EA57-8BA8-4C90-9AF0-465067E3EB9A@oracle.com> Hi Lance, Looks good. I was wondering whether you might want to delete the files using jdk.test.lib.util.FileUtils.deleteFileIfExistsWithRetry() instead. Brian > On Aug 6, 2019, at 1:31 PM, Lance Andersen wrote: > > Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 >, where ZipFile does not return the correct size from the CEN when the Zip64 Extended Information Extra Field is used to store the entry size > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html > > > Mach5 jdk tier1-tier3 all pass From lance.andersen at oracle.com Wed Aug 7 16:33:21 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Aug 2019 12:33:21 -0400 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <78C1EA57-8BA8-4C90-9AF0-465067E3EB9A@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> <78C1EA57-8BA8-4C90-9AF0-465067E3EB9A@oracle.com> Message-ID: <8B71F962-D9A5-4891-B69A-E0EE7DA4BA92@oracle.com> Hi Brian, > On Aug 7, 2019, at 12:21 PM, Brian Burkhalter wrote: > > Hi Lance, > > Looks good. thank you > I was wondering whether you might want to delete the files using jdk.test.lib.util.FileUtils.deleteFileIfExistsWithRetry() instead. I thought about it but decided it was not needed at least now given the files are only used by this test and the scratch directory will get cleaned up anyways. If you think I should add the library I can, just did not see it warranted at least for now. Just let me know :-) Thank you for the review > > Brian > >> On Aug 6, 2019, at 1:31 PM, Lance Andersen > wrote: >> >> Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 >, where ZipFile does not return the correct size from the CEN when the Zip64 Extended Information Extra Field is used to store the entry size >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html > >> >> Mach5 jdk tier1-tier3 all pass > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Wed Aug 7 16:39:00 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Aug 2019 09:39:00 -0700 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <8B71F962-D9A5-4891-B69A-E0EE7DA4BA92@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> <78C1EA57-8BA8-4C90-9AF0-465067E3EB9A@oracle.com> <8B71F962-D9A5-4891-B69A-E0EE7DA4BA92@oracle.com> Message-ID: <7A9975A4-F8F2-4494-909C-57B9E9DDA553@oracle.com> Hi Lance, > On Aug 7, 2019, at 9:33 AM, Lance Andersen wrote: > > I thought about it but decided it was not needed at least now given the files are only used by this test and the scratch directory will get cleaned up anyways. I thought that might be the case. > If you think I should add the library I can, just did not see it warranted at least for now. Just let me know :-) I think it?s fine. > Thank you for the review You?re welcome. Brian From alexey.semenyuk at oracle.com Wed Aug 7 16:47:29 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 7 Aug 2019 12:47:29 -0400 Subject: RFR: JDK-8229252 : Add descriptions to Windows jtreg tests In-Reply-To: <1b44fb45-2eef-cfe3-c5a2-ca1b72bc26d1@oracle.com> References: <1b44fb45-2eef-cfe3-c5a2-ca1b72bc26d1@oracle.com> Message-ID: <78fa6a8a-a929-82db-042e-36571a97aa84@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Add comments to Windows jtreg tests to help SQE setup their testing. [1] https://bugs.openjdk.java.net/browse/JDK-8229252 [2] http://cr.openjdk.java.net/~asemenyuk/8229252/webrev.00/ Thanks, Alexey From pavel.rappo at oracle.com Wed Aug 7 17:18:13 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 7 Aug 2019 18:18:13 +0100 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: References: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com>

Message-ID: <015C7EC6-4B92-4356-A0F1-5F1648BB5934@oracle.com> Roger, thank you for looking at this. While we might hear (on some of your questions) from Chris soon, I just have to ask about this one > On 7 Aug 2019, at 16:52, Roger Riggs wrote: > > 238: isRunning should be synchronized(lock) to make sure each Thread sees the same value threads that update it in start() and close() What makes you think they can see something different? Even though the result of this call is immediately outdated, the changes to the state made by start/close should be propagated as per JMM. From Roger.Riggs at oracle.com Wed Aug 7 17:42:20 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 7 Aug 2019 13:42:20 -0400 Subject: ProcessHandle.Info startInstant() drifts with system time on Linux In-Reply-To: <1565177641838.63922@ssi-schaefer.com> References: <1565177641838.63922@ssi-schaefer.com> Message-ID: <3190f880-7a18-e931-cf36-864ed9a10586@oracle.com> Hi Markus, core-libs-dev at openjdk.java.net is the more appropriate list for this question. The ProcessHandle info is based directly on the OS information about a process, there is no separate information stored or kept. If Linux had a stable way to represent the start time it would be reflected in the ProcessHandle info. Changing the clock on any running system is fraught.? So many time related actions depend on linear and/or monotonic progression of time. Re-reading the boot time would be a performance hit and be subject to a race condition with setting time. The process handle also uses the start time to validate a ProcessHandle; since the cached boot time does not change the value is stable for that check. A workaround for your application might be to save the relative start time by reading the boot time directly from /proc or the relative start time from /proc. Roger On 8/7/19 7:34 AM, Duft Markus wrote: > Hey, > > > Just checking in to see whether this is a bug, or by design (and where I should report this if it /is/ a bug :)). > > > We discovered, that ProcessHandle.Info.startInstant() seems to be non-constant for a given long running process when restarting the Java VM. We have a deployment tool (https://bdeploy.io) which monitors processes and tries to recover running process information when starting up. The general process would be: > > > 1) Start BDeploy > > 2) BDeploy starts a child process, records its PID and startInstant to be able to find it again later > > 3) BDeploy is stopped (for whatever reason) and the child process keeps running (we do make sure that this is the case :)). > > 4) BDeploy is started again, tries to find running processes from its previous life to resume monitoring. > > 5) BDeploy reads PID and startInstant from a file, finds a ProcessHandle using the PID and compares the startInstant. This is to avoid finding wrong processes when PIDs wrap. > > > Now we have the problem that this does not work always. Analysis have led us to the point where we identifier NTPD or manual clock setting as the root cause. It seems that a system clock change will change the absolute timestamp of a process start. I had a look at the JDK sources and found that this is actually true :) Here is what I found out and documented on our own bugtracker: > > > The relevant java native method on l??inux does this: > > /* > * Try to stat and then open /proc/%d/stat > */ > snprintf(fn, sizeof fn, "/proc/%d/stat", pid); > > fp = fopen(fn, "r"); > ... > > // Scan the needed fields from status, retaining only ppid(4), > // utime (14), stime(15), starttime(22) > if (4 != sscanf(s, " %*c %d %*d %*d %*d %*d %*d %*u %*u %*u %*u %lu %lu %*d %*d %*d %*d %*d %*d %llu", > &parentPid, &utime, &stime, &start)) { > return 0; // not all values parsed; return error > } > > *totalTime = (utime + stime) * (jlong)(1000000000 / clock_ticks_per_second); > > *startTime = bootTime_ms + ((start * 1000) / clock_ticks_per_second); > ... > > > So the process start time is calculated rela?tive to the system kernel boot time. The boot time is calculated ONCE when starting the java VM like this: > > fp = fopen("/proc/stat", "r"); > ... > > while (getline(&line, &len, fp) != -1) { > if (sscanf(line, "btime %llu", &bootTime) == 1) { > break; > } > } > ... > > return bootTime * 1000; > > > However, the /proc/stat btime field does not seem to be constant. When I manually set the clock 2 minutes ahead, the btime field follows along, and is now two minutes later than before. Thus any system time correction (manual, ntpd, ...) will change the system boot time, which will make the timestamp different, but only after restarting the JVM. > > This is IMHO a bug in the JVM. The btime is a relative timestamp (uptime in nanoseconds if i'm correct). The absolute representation of this timestamp is calculated on the fly when reading /proc/stat from the current date/time (assuming that the current date/time is correct). This is not a problem (and correct!) for a human reader. The field should just never be taken to calculate another absolute timestamp, which java does... > > So we pseudo-have: > bootTime_ms > btime = current-clock-timestamp - kernel-uptime; > > proc-start = btime + process-uptime; > > All three variables are mutable and may (and will) change. If (and only if) kernel-uptime and process-uptime are updated correctly, calculating the absolute start-time will yield a reproducible result only as long as the system clock does not change. > > > I'm pretty sure this qualifies as bug, but not whether it's a java a kernel (or whatever) bug... Any advice, also how to get around this, would be greatly appreciated. I would really like to avoid hard-coding allowed drift ranges or something like this, especially as we'll be running into timezone, summer time, etc. issues AFAICT... > > > Cheers, > > Thanks for ANY help, > > Markus > > SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria > Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300 > Commercial Court: Landesgericht f?r Zivilrechtssachen Graz > Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier. > You can find our information on the handling of personal data here. From Roger.Riggs at oracle.com Wed Aug 7 17:49:04 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 7 Aug 2019 13:49:04 -0400 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: <015C7EC6-4B92-4356-A0F1-5F1648BB5934@oracle.com> References: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com>

<015C7EC6-4B92-4356-A0F1-5F1648BB5934@oracle.com> Message-ID: Hi Pavel, You are correct, state is volatile. It seemed unnecessary/redundant since except for isRunning it is updated inside a synchronize(lock). The synchronized(socketList) is also unnecessary since it is already synchronized on lock. Roger On 8/7/19 1:18 PM, Pavel Rappo wrote: > Roger, thank you for looking at this. While we might hear (on some of your > questions) from Chris soon, I just have to ask about this one > >> On 7 Aug 2019, at 16:52, Roger Riggs wrote: >> >> 238: isRunning should be synchronized(lock) to make sure each Thread sees the same value threads that update it in start() and close() > What makes you think they can see something different? Even though the result of > this call is immediately outdated, the changes to the state made by start/close > should be propagated as per JMM. > > > From martinrb at google.com Wed Aug 7 18:37:42 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Aug 2019 11:37:42 -0700 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Message-ID: Thanks for fixing this. Looks good. The APPNOTE.TXT spec is very confusing and surprising - it is not at all obvious why the size fields are required in the LOC ZIP64 header but not in the CEN ZIP64 header. I might include a reference to the sections in the PKWARE spec - 4.5.3 and 4.4.9 It seems to be related to encryption, which the openjdk implementation does not support. It seems to be still required to store 0xFFFFFFFF in the regular LOC header when the ZIP64 extra field is present, so it looks to me like the LOC and CEN handling can be unified, again assuming no encryption support. On Tue, Aug 6, 2019 at 1:32 PM Lance Andersen wrote: > Hi > > Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 > , where ZipFile does > not return the correct size from the CEN when the Zip64 Extended > Information Extra Field is used to store the entry size > > The webrev can be found at > http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html < > http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html> > > Mach5 jdk tier1-tier3 all pass > > Best > Lance > > > < > http://oracle.com/us/design/oracle-email-sig-198324.gif> > 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 pavel.rappo at oracle.com Wed Aug 7 18:39:15 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 7 Aug 2019 19:39:15 +0100 Subject: RFR [14] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: References: <8F91C8DB-30C0-4EDF-9933-EAFB5FE34D8D@oracle.com>

<015C7EC6-4B92-4356-A0F1-5F1648BB5934@oracle.com> Message-ID: > On 7 Aug 2019, at 18:49, Roger Riggs wrote: > > > > It seemed unnecessary/redundant since except for isRunning it is updated inside a synchronize(lock). Pardon, what seemed unnecessary? > The synchronized(socketList) is also unnecessary since it is already synchronized on lock. You are right, this is redundant, albeit harmless. It might be a leftover from one of the design iterations we've had when synchronization was more fine-grained. I'll remove all the synchronization on `socketList`. Thanks. From lance.andersen at oracle.com Wed Aug 7 18:52:05 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Aug 2019 14:52:05 -0400 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> Message-ID: <90B3409F-3B00-46F8-A129-419BEB20C16C@oracle.com> Hi Martin, > On Aug 7, 2019, at 2:37 PM, Martin Buchholz wrote: > > Thanks for fixing this. Looks good. Thank you. > The APPNOTE.TXT spec is very confusing and surprising - it is not at all obvious why the size fields are required in the LOC ZIP64 header but not in the CEN ZIP64 header. > I might include a reference to the sections in the PKWARE spec - 4.5.3 and 4.4.9 > It seems to be related to encryption, which the openjdk implementation does not support. > It seems to be still required to store 0xFFFFFFFF in the regular LOC header when the ZIP64 extra field is present, so it looks to me like the LOC and CEN handling can be unified, again assuming no encryption support. I wanted to be careful as to not tweak this code too much in one pass given its age. So its on my todo list to spend some more time looking at this but moving in small steps to not rock the apple cart :-) Yes, I do find APPNOTE.TXT somewhat confusing along with the references to info-zip; I really want to tread lightly while I continue to become more familiar with this code. Hope that makes sense :-) > > On Tue, Aug 6, 2019 at 1:32 PM Lance Andersen > wrote: > Hi > > Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 >, where ZipFile does not return the correct size from the CEN when the Zip64 Extended Information Extra Field is used to store the entry size > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html > > > Mach5 jdk tier1-tier3 all pass > > Best > Lance > > > > > > > >Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From alexander.matveev at oracle.com Wed Aug 7 19:08:50 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 7 Aug 2019 12:08:50 -0700 Subject: RFR: JDK-8229252 : Add descriptions to Windows jtreg tests In-Reply-To: <78fa6a8a-a929-82db-042e-36571a97aa84@oracle.com> References: <1b44fb45-2eef-cfe3-c5a2-ca1b72bc26d1@oracle.com> <78fa6a8a-a929-82db-042e-36571a97aa84@oracle.com> Message-ID: <238e507a-6a5f-5276-d469-6de9018691f4@oracle.com> Hi Alexey, Looks good. Thanks, Alexander On 8/7/2019 9:47 AM, Alexey Semenyuk wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Add comments to Windows jtreg tests to help SQE setup their testing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8229252 > > [2] http://cr.openjdk.java.net/~asemenyuk/8229252/webrev.00/ > > Thanks, > Alexey > From martinrb at google.com Wed Aug 7 19:41:28 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Aug 2019 12:41:28 -0700 Subject: RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries In-Reply-To: <90B3409F-3B00-46F8-A129-419BEB20C16C@oracle.com> References: <8BDEF87A-B6BF-4335-B646-74EEAA4C10AB@oracle.com> <90B3409F-3B00-46F8-A129-419BEB20C16C@oracle.com> Message-ID: Thanks for joining the small club of zip implementers. No one likes the ZIP file format, but the power of a legacy data interchange format is great. On Wed, Aug 7, 2019 at 11:54 AM Lance Andersen wrote: > Hi Martin, > > On Aug 7, 2019, at 2:37 PM, Martin Buchholz wrote: > > Thanks for fixing this. Looks good. > > > Thank you. > > > The APPNOTE.TXT spec is very confusing and surprising - it is not at all > obvious why the size fields are required in the LOC ZIP64 header but not in > the CEN ZIP64 header. > I might include a reference to the sections in the PKWARE spec - 4.5.3 and > 4.4.9 > It seems to be related to encryption, which the openjdk implementation > does not support. > It seems to be still required to store 0xFFFFFFFF in the regular LOC > header when the ZIP64 extra field is present, so it looks to me like the > LOC and CEN handling can be unified, again assuming no encryption support. > > > I wanted to be careful as to not tweak this code too much in one pass > given its age. So its on my todo list to spend some more time looking at > this but moving in small steps to not rock the apple cart :-) > > Yes, I do find APPNOTE.TXT somewhat confusing along with the references to > info-zip; I really want to tread lightly while I continue to become more > familiar with this code. > > Hope that makes sense :-) > > > > On Tue, Aug 6, 2019 at 1:32 PM Lance Andersen > wrote: > >> Hi >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8226530 < >> https://bugs.openjdk.java.net/browse/JDK-8226530>, where ZipFile does >> not return the correct size from the CEN when the Zip64 Extended >> Information Extra Field is used to store the entry size >> >> The webrev can be found at >> http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html < >> http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html> >> >> Mach5 jdk tier1-tier3 all pass >> >> Best >> Lance >> >> >> < >> http://oracle.com/us/design/oracle-email-sig-198324.gif> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From naoto.sato at oracle.com Wed Aug 7 20:12:17 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 7 Aug 2019 13:12:17 -0700 Subject: [14] RFR: 8215181: Accounting currency format support In-Reply-To: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> Message-ID: Ping. Naoto On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8215181 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8215181/webrev.00/ > > This is to enable "accounting" style currency formatting (negative > values in parentheses) with CLDR. > > Naoto From lance.andersen at oracle.com Wed Aug 7 20:17:26 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Aug 2019 16:17:26 -0400 Subject: [14] RFR: 8215181: Accounting currency format support In-Reply-To: References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> Message-ID: <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com> Hi Naoto, I looked over the proposed changes and the bug. They seem reasonable to me. Best Lance > On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com wrote: > > Ping. > > Naoto > > On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote: >> Hi, >> Please review the fix to the following issue: >> https://bugs.openjdk.java.net/browse/JDK-8215181 >> The proposed changeset is located at: >> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/ >> This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR. >> Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Wed Aug 7 20:20:52 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Aug 2019 16:20:52 -0400 Subject: [14] RFR: 8215181: Accounting currency format support In-Reply-To: <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com> References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com> Message-ID: Hi again Naoto, I meant to ask is there a CSR due to the change in the javadoc for NumberFormat? If not, there probably should > On Aug 7, 2019, at 4:17 PM, Lance Andersen wrote: > > Hi Naoto, > > I looked over the proposed changes and the bug. They seem reasonable to me. > > Best > Lance >> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com wrote: >> >> Ping. >> >> Naoto >> >> On 7/31/19 5:57 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> Please review the fix to the following issue: >>> https://bugs.openjdk.java.net/browse/JDK-8215181 >>> The proposed changeset is located at: >>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/ >>> This is to enable "accounting" style currency formatting (negative values in parentheses) with CLDR. >>> Naoto > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Wed Aug 7 20:24:29 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 7 Aug 2019 13:24:29 -0700 Subject: [14] RFR: 8215181: Accounting currency format support In-Reply-To: References: <9fa22b0e-5d07-964f-d95e-f7c33e924df6@oracle.com> <584A990F-6F64-4C47-86E6-5B1121F0DFF0@oracle.com> Message-ID: <3a190aa4-cf6b-ba1c-4dfb-77bdea5b3712@oracle.com> Thanks for the review, Lance. Yes, CSR is needed and it is already approved: https://bugs.openjdk.java.net/browse/JDK-8218770 Naoto On 8/7/19 1:20 PM, Lance Andersen wrote: > Hi again Naoto, > > I meant to ask is there a CSR due to the change in the javadoc for > NumberFormat? ?If not, there probably should > > >> On Aug 7, 2019, at 4:17 PM, Lance Andersen > > wrote: >> >> Hi Naoto, >> >> I looked over the proposed changes and the bug. ?They seem reasonable >> to me. >> >> Best >> Lance >>> On Aug 7, 2019, at 4:12 PM, naoto.sato at oracle.com >>> wrote: >>> >>> Ping. >>> >>> Naoto >>> >>> On 7/31/19 5:57 PM, naoto.sato at oracle.com >>> wrote: >>>> Hi, >>>> Please review the fix to the following issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8215181 >>>> The proposed changeset is located at: >>>> https://cr.openjdk.java.net/~naoto/8215181/webrev.00/ >>>> This is to enable "accounting" style currency formatting (negative >>>> values in parentheses) with CLDR. >>>> Naoto >> >>