From hohensee at amazon.com Sat Feb 1 09:24:06 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 1 Feb 2020 09:24:06 +0000 Subject: [8u] RFR Backport 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <3d895832-ccc9-d3d6-7205-b9127570b947@redhat.com> References: <3d895832-ccc9-d3d6-7205-b9127570b947@redhat.com> Message-ID: Lgtm. I spot-checked just the dsig tests, which passed. Paul ?On 1/31/20, 2:09 PM, "jdk8u-dev on behalf of Elliott Baron" wrote: On 2020-01-20 5:20 p.m., Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8046724 to 8u. This change is a > dependency that will help us do a cleaner backport of "8177334: Update > xmldsig implementation to Apache Santuario 2.1.1". > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8046724 > https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eed55a6ebaa3 > > The JDK 9 changeset did not apply cleanly. Here are the modifications I > had to make to backport this to 8u: > > DOMKeyValue.java: > - Also removes commented out java.io.IOException import statement, which > would have been removed by "8046949: Generify the javax.xml.crypto API", > which I didn't backport since it changes API. This changeset effectively > uncomments this statement, since IOException is used once again. > - Edited strings in code deleted by this changeset from > "sun.security.util.ECParameters" to "sun.security.ec.ECParameters". This > is because "8035166: Remove dependency on EC classes from pkcs11 > provider" is not in 8u. > > GenerationTests.java: > - Copyright header already updated to newer date by "8206911: > javax/xml/crypto/dsig/GenerationTests.java fails in 8u-dev". > - jtreg tag is missing "8046949: Generify the javax.xml.crypto API". The > tag includes two bugs newer than this one: "8074784: Additional tests > for XML DSig API", and "8210736: > jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux". > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8046724/webrev.00/ > > Testing: x86_64 build, jdk_tier1, jdk_security tests I still need a review for this, when someone has a chance to take a look. Thanks, Elliott From felix.yang at huawei.com Mon Feb 3 04:04:11 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 3 Feb 2020 04:04:11 +0000 Subject: [Ping] Re: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph In-Reply-To: <56a9412c-0492-26c7-6c64-dc1608318b83@redhat.com> References: <56a9412c-0492-26c7-6c64-dc1608318b83@redhat.com> Message-ID: > It looks like I got as far as opening the bug up in my web browser... :/ > > Anyway, patch looks good to me too. Seems the set_ctrl addition was made by > the 8u backport of JDK-8173770. Thanks for reviewing this. I see it was marked with label jdk8u-fix-yes. Could someone help push it please? 8u backport webrev : http://cr.openjdk.java.net/~fyang/8146792-backport/webrev.00/ Best regards, Felix From gnu.andrew at redhat.com Mon Feb 3 06:38:14 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 3 Feb 2020 06:38:14 +0000 Subject: [Ping] Re: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph In-Reply-To: References: <56a9412c-0492-26c7-6c64-dc1608318b83@redhat.com> Message-ID: <29764fb4-cb34-663d-87a9-d8b64eb11b4c@redhat.com> On 03/02/2020 04:04, Yangfei (Felix) wrote: >> It looks like I got as far as opening the bug up in my web browser... :/ >> >> Anyway, patch looks good to me too. Seems the set_ctrl addition was made by >> the 8u backport of JDK-8173770. > > Thanks for reviewing this. I see it was marked with label jdk8u-fix-yes. > Could someone help push it please? 8u backport webrev : http://cr.openjdk.java.net/~fyang/8146792-backport/webrev.00/ > > Best regards, > Felix > Done. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Feb 3 16:42:20 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 3 Feb 2020 16:42:20 +0000 Subject: [8u] RFR Backport 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <3d895832-ccc9-d3d6-7205-b9127570b947@redhat.com> References: <3d895832-ccc9-d3d6-7205-b9127570b947@redhat.com> Message-ID: On 31/01/2020 22:02, Elliott Baron wrote: > On 2020-01-20 5:20 p.m., Elliott Baron wrote: >> Hi, >> >> I'd like to request a review to backport 8046724 to 8u. This change is >> a dependency that will help us do a cleaner backport of "8177334: >> Update xmldsig implementation to Apache Santuario 2.1.1". >> >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8046724 >> https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eed55a6ebaa3 >> >> The JDK 9 changeset did not apply cleanly. Here are the modifications >> I had to make to backport this to 8u: >> >> DOMKeyValue.java: >> - Also removes commented out java.io.IOException import statement, >> which would have been removed by "8046949: Generify the >> javax.xml.crypto API", which I didn't backport since it changes API. >> This changeset effectively uncomments this statement, since >> IOException is used once again. >> - Edited strings in code deleted by this changeset from >> "sun.security.util.ECParameters" to "sun.security.ec.ECParameters". >> This is because "8035166: Remove dependency on EC classes from pkcs11 >> provider" is not in 8u. >> >> GenerationTests.java: >> - Copyright header already updated to newer date by "8206911: >> javax/xml/crypto/dsig/GenerationTests.java fails in 8u-dev". >> - jtreg tag is missing "8046949: Generify the javax.xml.crypto API". >> The tag includes two bugs newer than this one: "8074784: Additional >> tests for XML DSig API", and "8210736: >> jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux". >> >> 8u webrev: >> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8046724/webrev.00/ >> >> Testing: x86_64 build, jdk_tier1, jdk_security tests > > I still need a review for this, when someone has a chance to take a look. > > Thanks, > Elliott > Looks good to me, too. If you flag the bug with jdk8u-fix-yes, I'll approve. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Feb 3 19:19:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 3 Feb 2020 20:19:57 +0100 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: Hi, Not sure why this is RFC, while we actually need to RFR this integration very carefully, as it touches many delicate parts of VM. So, treating this as code review below. Comments from the cursory look: On 1/30/20 12:37 PM, Mario Torre wrote: > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ *) I am a bit concerned about the removal/rename of trace->jfr, as it would probably break some downstream things, at least for a while. I hope that is the informed risk taking. *) Not sure why new jdk8u252-b01 is in .hgtags there, also THIRD_PARTY_README changes. *) makefiles/buildtree.make make/linux/makefiles/buildtree.make make/solaris/makefiles/buildtree.make Indent seems to be missing at new ALWAYS_EXCLUDE_DIRS lines. *) make/bsd/makefiles/vm.make: make/linux/makefiles/vm.make: make/solaris/makefiles/vm.make: Indent seems to be missing at new EXCLUDE_JFR_PATHS lines. *) make/windows/makefiles/compile.make: How does this change relate to JFR? - 349 /D "HS_COMPANY=$(HS_COMPANY)" \ + 356 /D "HS_COMPANY=$(COMPANY_NAME)" \ *) make/windows/makefiles/defs.make: Ditto, how do the hunks around the VENDOR/COMPANY names relate to JFR? *) make/windows/makefiles/vm.make: Ditto, plus hunks around iphlp_interface.obj, vm_version.obj, arguments.obj, etc? *) src/os/linux/vm/perfMemory_linux.cpp: Unclear what new include does there. There are no other changes in this compilation unit! It should also be stylistically identical to other include lines, e.g. have the space after "#". *) src/os/posix/vm/os_posix.cpp: Unclear what ThreadCrashProtection has to do with JFR. The hunk seems to be coming into jdk/jdk from JDK-8020701 and rename in JDK-8183925. Neither are listed as backports. *) src/share/vm/classfile/classLoader.cpp: src/share/vm/classfile/systemDictionary.cpp: Not sure if we need to repackage the instanceKlassHandle here. Maybe I am missing something? *) src/share/vm/classfile/systemDictionary.cpp The "else" branch near find_or_define_instance_class looks dodgy. I believe it is cleaner to do this: // find_or_define_instance_class may return a different InstanceKlass if (!k.is_null()) { k = find_or_define_instance_class(class_name, class_loader, k, CHECK_(nh)); } #if INCLUDE_JFR if (k.is_null() && (class_name == jfr_event_handler_proxy)) { ... } #endif // INCLUDE_JFR *) src/share/vm/compiler/compileBroker.cpp: Stars are misaligned ;) 2026 const char *failure_reason = ci_env.failure_reason(); 2027 const char* retry_message = ci_env.retry_message(); *) vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp: It feels safer to stub out implementations like this with INCLUDE_JFR. I would trust compilers to inline/eliminate the empty method, but would not trust them to eliminate all the method body. So it feels safer to e.g: inline void PSPromotionManager::promotion_trace_event(oop new_obj, oop old_obj, size_t obj_size, uint age, bool tenured, const PSPromotionLAB* lab) { #if INCLUDE_JFR ... #endif } *) src/share/vm/gc_implementation/shared/gcTraceSend.cpp Commented out code, starts with "// XXX" at L236? *) src/share/vm/opto/node.cpp New #pragmas related to JFR how? *) src/share/vm/opto/superword.hpp "// JVMCI: OrderedPair is moved up", and this relates to JFR how? *) src/share/vm/prims/whitebox.cpp: src/share/vm/prims/whitebox.hpp: Additions of WB_EnqueueInitializerForCompilation, WB_GetHeapAlignment and related rewrite is related to JFR how? *) src/share/vm/runtime/biasedLocking.cpp I would sleep a bit better, if this was protected by INCLUDE_JFR: 259 // If requested, return information on which thread held the bias 260 if (biased_locker != NULL) { 261 *biased_locker = biased_thread; 262 } 263 ...and: 502 if (biased_locker != NULL) { 503 _biased_locker_id = JFR_THREAD_ID(biased_locker); 504 } *) src/share/vm/runtime/globals.hpp: Not sure what new default arguments for CommandLineFlags::*at are for in this changeset. *) src/share/vm/runtime/safepoint.cpp: Missing EventSafepointCleanupTask for "rotating gc logs", a recent addition to 8u. *) src/share/vm/runtime/synchronizer.cpp: Commented out code: 1188 // XXX no such counters. implement? 1189 // event->set_cause((u1)cause); *) src/share/vm/services/diagnosticArgument.cpp src/share/vm/services/memTracker.hpp src/share/vm/utilities/bitMap.inline.hpp The changes do not seem related to JFR. *) src/share/vm/runtime/mutexLocker.cpp src/share/vm/runtime/mutexLocker.hpp "#ifdef INCLUDE_JFR" is correct, should be "#if INCLUDE_JFR"? > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ *) make/CopyIntoClasses.gmk: Why L95..L99 are commented out? *) make/CreateJars.gmk: Indents seem foobared. *) src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java How is this change related to JFR? *) test/TEST.groups: Double new-line? *) I have not reviewed the rest of the bulk additions. Those seem to be pretty self-contained. > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/ *) Not sure why new jdk8u252-b01 is in .hgtags there, also THIRD_PARTY_README changes. --- Thanks, -Aleksey From denghui.ddh at alibaba-inc.com Tue Feb 4 03:59:02 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 04 Feb 2020 11:59:02 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiA4MjM2MTYwOiBNaXNzaW5nIFRocmVhZENyYXNoUHJvdGVj?= =?UTF-8?B?dGlvbiBmb3IgSkZSIGluIHNpZ25hbCBoYW5kbGVy?= In-Reply-To: <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com>, <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> Message-ID: <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> Hi Andrew, I'm so sorry for the late reply. You are right, backport is a simpler way, so I make a webrev for the backport of JDK-8183925 for jdk8u-jfr-incubator.(Not sure should I create a new thread for this backport) The webrev has some obvious differences with the original changeset because some codes had been introduced in JDK-8223147. Please help review it. Webrev: http://cr.openjdk.java.net/~ddong/8183925/ Jira: https://bugs.openjdk.java.net/browse/JDK-8183925 Original changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/786437c6344b Denghui Dong ------------------------------------------------------------------ From:Andrew Dinn Send Time:2019?12?19?(???) 21:52 To:???(??) ; jdk8u-dev Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler On 19/12/2019 02:52, Denghui Dong wrote: > Hi Andrew, > Thanks for the reply. > As I said in my last message, merging os::ThreadCrashProtection and > os::WatcherThreadCrashProtection is a more elegant way, > actually this work was done by > JDK-8183925(Decouple crash protection from watcher thread), but it's not > JFR-related. > And the first patch of JFR-backport use os::ThreadCrashProtection to > protect jfr thread sampler crash, but miss check_crash_protection in the > signal handler, > so I made the changeset. > Do you think we should backport JDK-8183925 to jdk8u-jfr-incubator? I'm still not at all clear what you /have/ backported. Your patch inserts calls to os::ThreadCrashProtection::check_crash_protection(sig, t); into the code that calls os::WatcherThreadCrashProtection::check_crash_protection() If you have not already backported JDK-8183925 then how can those calls be valid? Have you just backported some of the patch? For example, have you added os::ThreadCrashProtection to jdk8u-jfr-incubator without removing WatcherThreadCrashProtection? If so then why woudld you not instead simply backport all of JDK-8183925? regards, Andrew Dinn ----------- > ------------------------------------------------------------------ > From:Andrew Dinn > Send Time:2019?12?19?(???) 01:17 > To:???(??) ; jdk8u-dev > > Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection > for JFR in signal handler > > Hi Denghui, > > On 18/12/2019 06:37, Denghui Dong wrote: > > Hi all, > > Please help review the following changeset: > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236160 > > Webrev: http://cr.openjdk.java.net/~ddong/8236160/webrev.00/hotspot.changeset > > Summary: > > JFR thread sampler uses ThreadCrashProtection to protect thread crash, so it's necessary to call > > ThreadCrashProtection::check_crash_protection in signal handler. > > And a more elegant way is to merge ThreadCrashProtection and WatcherThreadCrashProtection, but this changeset didn't do that. > I'm not clear why you are calling both > > os::WatcherThreadCrashProtection::check_crash_protection(sig, t); > > and > > os::ThreadCrashProtection::check_crash_protection(sig, t); > > Is it not possible simply to rely on os::ThreadCrashProtection alone as > happens updtream? > > I am assuming that you have already back-ported class > os::ThreadCrashProtection to the JFR incubator repo? Did you need to > change it's behaviour in any way in order to do that? Does that have > anything to do with why your are calling both routines? > > Also, how have you tested this patch? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From gnu.andrew at redhat.com Tue Feb 4 05:25:03 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 4 Feb 2020 05:25:03 +0000 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: <4b82d24b-8353-83b7-f80f-1f94d750669d@redhat.com> On 03/02/2020 19:19, Aleksey Shipilev wrote: > Hi, > > Not sure why this is RFC, while we actually need to RFR this integration very carefully, as it > touches many delicate parts of VM. So, treating this as code review below. First, thanks for looking over this. I haven't had chance myself yet, but intend to before it goes in. I agree it should be an RFR, but it's also not a straight-forward code review, but a merge. Thus, all the changes should (in theory) have already been reviewed and so, any further changes warrant a new bug, fixed either in the incubator before integration or after. > > Comments from the cursory look: > > On 1/30/20 12:37 PM, Mario Torre wrote: >> https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ > > *) I am a bit concerned about the removal/rename of trace->jfr, as it would probably break some > downstream things, at least for a while. I hope that is the informed risk taking. > Agreed. This looked odd to me in doing the merge. > *) Not sure why new jdk8u252-b01 is in .hgtags there, also THIRD_PARTY_README changes. > I think you'd be better considering the merge changesets, not the webrev: https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/merge.changeset https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/merge.changeset https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/merge.changeset The webrev is based against jdk8u252-b01 so it does pick up some post-jdk8u252-b01 that are already in the 8u-dev repos. I'm sure you're familiar with this from our Shenandoah merges. The webrevs are provided for easier navigation, but the merge changesets should be the official source on what is actually being changed. > *) makefiles/buildtree.make > make/linux/makefiles/buildtree.make > make/solaris/makefiles/buildtree.make > Indent seems to be missing at new ALWAYS_EXCLUDE_DIRS lines. > > *) make/bsd/makefiles/vm.make: > make/linux/makefiles/vm.make: > make/solaris/makefiles/vm.make: > Indent seems to be missing at new EXCLUDE_JFR_PATHS lines. > Maybe a cleanup patch is warranted then? > *) make/windows/makefiles/compile.make: > How does this change relate to JFR? > - 349 /D "HS_COMPANY=$(HS_COMPANY)" \ > + 356 /D "HS_COMPANY=$(COMPANY_NAME)" \ > > *) make/windows/makefiles/defs.make: > Ditto, how do the hunks around the VENDOR/COMPANY names relate to JFR? > > *) make/windows/makefiles/vm.make: > Ditto, plus hunks around iphlp_interface.obj, vm_version.obj, arguments.obj, etc? > See comments above about the webrev. These are "8233995: java.vm.vendor (and potentially other properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8" > *) src/os/linux/vm/perfMemory_linux.cpp: > Unclear what new include does there. There are no other changes in this compilation unit! It > should also be stylistically identical to other include lines, e.g. have the space after "#". > > *) src/os/posix/vm/os_posix.cpp: > Unclear what ThreadCrashProtection has to do with JFR. The hunk seems to be coming into jdk/jdk > from JDK-8020701 and rename in JDK-8183925. Neither are listed as backports. 8020701 does seem to be in 8u, so maybe I've misunderstood you here: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5e3b6f79d280 > > *) src/share/vm/classfile/classLoader.cpp: > src/share/vm/classfile/systemDictionary.cpp: > Not sure if we need to repackage the instanceKlassHandle here. Maybe I am missing something? > > *) src/share/vm/classfile/systemDictionary.cpp > The "else" branch near find_or_define_instance_class looks dodgy. I believe it is cleaner to do this: > > // find_or_define_instance_class may return a different InstanceKlass > if (!k.is_null()) { > k = find_or_define_instance_class(class_name, class_loader, k, CHECK_(nh)); > } > #if INCLUDE_JFR > if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > ... > } > #endif // INCLUDE_JFR > > *) src/share/vm/compiler/compileBroker.cpp: > Stars are misaligned ;) > 2026 const char *failure_reason = ci_env.failure_reason(); > 2027 const char* retry_message = ci_env.retry_message(); > > *) vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp: > It feels safer to stub out implementations like this with INCLUDE_JFR. I would trust compilers to > inline/eliminate the empty method, but would not trust them to eliminate all the method body. So it > feels safer to e.g: > > inline void PSPromotionManager::promotion_trace_event(oop new_obj, oop old_obj, > size_t obj_size, > uint age, bool tenured, > const PSPromotionLAB* lab) { > #if INCLUDE_JFR > ... > #endif > } > > *) src/share/vm/gc_implementation/shared/gcTraceSend.cpp > Commented out code, starts with "// XXX" at L236? > > *) src/share/vm/opto/node.cpp > New #pragmas related to JFR how? > > *) src/share/vm/opto/superword.hpp > "// JVMCI: OrderedPair is moved up", and this relates to JFR how? > > *) src/share/vm/prims/whitebox.cpp: > src/share/vm/prims/whitebox.hpp: > Additions of WB_EnqueueInitializerForCompilation, WB_GetHeapAlignment and related rewrite is > related to JFR how? > > *) src/share/vm/runtime/biasedLocking.cpp > I would sleep a bit better, if this was protected by INCLUDE_JFR: > > 259 // If requested, return information on which thread held the bias > 260 if (biased_locker != NULL) { > 261 *biased_locker = biased_thread; > 262 } > 263 > > ...and: > > 502 if (biased_locker != NULL) { > 503 _biased_locker_id = JFR_THREAD_ID(biased_locker); > 504 } > > *) src/share/vm/runtime/globals.hpp: > Not sure what new default arguments for CommandLineFlags::*at are for in this changeset. > > *) src/share/vm/runtime/safepoint.cpp: > Missing EventSafepointCleanupTask for "rotating gc logs", a recent addition to 8u. > > *) src/share/vm/runtime/synchronizer.cpp: > Commented out code: > > 1188 // XXX no such counters. implement? > 1189 // event->set_cause((u1)cause); > > *) src/share/vm/services/diagnosticArgument.cpp > src/share/vm/services/memTracker.hpp > src/share/vm/utilities/bitMap.inline.hpp > The changes do not seem related to JFR. > > *) src/share/vm/runtime/mutexLocker.cpp > src/share/vm/runtime/mutexLocker.hpp > > "#ifdef INCLUDE_JFR" is correct, should be "#if INCLUDE_JFR"? > > >> https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ > > *) make/CopyIntoClasses.gmk: > Why L95..L99 are commented out? > > *) make/CreateJars.gmk: > Indents seem foobared. > > *) src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java > How is this change related to JFR? > > *) test/TEST.groups: > Double new-line? > > *) I have not reviewed the rest of the bulk additions. Those seem to be pretty self-contained. > >> https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/ > > *) Not sure why new jdk8u252-b01 is in .hgtags there, also THIRD_PARTY_README changes. > > --- > Thanks, > -Aleksey > I'll let those who've worked on this comment on the rest. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From bradford.wetmore at oracle.com Tue Feb 4 23:24:01 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 4 Feb 2020 15:24:01 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 Message-ID: I added a simple PSS 32-bit windows crash fix, which was previously reviewed in security-dev earlier today [0]. 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION The PSS webrev is now at version .01. Otherwise, everything is identical from last week's request below. The ALPN remains at version .00. [0] https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html ---begin--- Good morning/afternoon/evening/night, As announced on jdk8u-dev[1], there is a Maintenance Release in progress for Java SE 8 (i.e. JSR 337) [2] to include two security features important for TLS 1.3: 1. Application-Layer Protocol Negotiation (ALPN) [3][4] 2. RSA Signature Scheme with Appendix: Probabilistic Signature Scheme (RSASSA-PSS) [5][6] As mentioned in [1], if it wasn't too much work then we would like to contribute the changes required by this MR to the next appropriate OpenJDK 8 release, most likely 8u252. Now that the MR3 balloting successfully concluded last night, I'd like to make that happen, and move the code into review. The code is essentially what was reviewed for 8u41[7][8] and internally for what we expect to be in Oracle's 8u251 JDK, except the code in this review is based on the current JDK 8u workspace. We also included code to allow the Windows platform to use PSS natively. The specific bugs/backports (requested by the JDK8u maintainers) follow: ALPN: ===== 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension (Java SE 8) 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension 8170282: Enable ALPN parameters to be supplied during the TLS handshake 8145849: ALPN: getHandshakeApplicationProtocol() always return null 8158978: ALPN not working when values are set directly on a SSLServerSocket 8171443: (spec) An ALPN callback function may also ignore ALPN RSASSA-PSS: =========== 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) 8146293: Add support for RSASSA-PSS Signature algorithm 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized 8213009: Refactoring existing SunMSCAPI classes 8213010: Supporting keys created with certmgr.exe 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails 8215694: keytool cannot generate RSASSA-PSS certificates 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange 8223003: SunMSCAPI keys are not cleaned up 8223063: Support CNG RSA keys 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support 8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId Reviewed-by: valeriep, weijun, coffeys, pkoppula Here are the reviews: 1. ALPN: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN 2. RSASSA-PSS: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS Most of these changes are direct copies of the changesets applied in JDK 9+, but adjusted for JDK 8u. Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were added to the SUN Provider to support the corresponding truncated RSASSA-PSS Signatures. Thanks, Brad [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html [2] https://www.jcp.org/en/jsr/detail?id=337 [3] https://bugs.openjdk.java.net/browse/JDK-8230977 [4] https://bugs.openjdk.java.net/browse/JDK-8233417 [5] https://bugs.openjdk.java.net/browse/JDK-8230978 [6] https://bugs.openjdk.java.net/browse/JDK-8233418 [7] https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ From xuelei.fan at oracle.com Wed Feb 5 01:08:59 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 4 Feb 2020 17:08:59 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> > 1. ALPN: > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN I reviewed this part, which look good to me. Thanks, Xuelei On 2/4/2020 3:24 PM, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.? The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > > ---begin--- > > Good morning/afternoon/evening/night, > > As announced on jdk8u-dev[1], there is a Maintenance Release in progress > for Java SE 8 (i.e. JSR 337) [2] to include two security features > important for TLS 1.3: > > 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] > 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme > (RSASSA-PSS) [5][6] > > As mentioned in [1], if it wasn't too much work then we would like to > contribute the changes required by this MR to the next appropriate > OpenJDK 8 release, most likely 8u252. > > Now that the MR3 balloting successfully concluded last night, I'd like > to make that happen, and move the code into review. > > The code is essentially what was reviewed for 8u41[7][8] and internally > for what we expect to be in Oracle's 8u251 JDK, except the code in this > review is based on the current JDK 8u workspace.? We also included code > to allow the Windows platform to use PSS natively. > > The specific bugs/backports (requested by the JDK8u maintainers) follow: > > ALPN: > ===== > 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension (Java SE 8) > 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension > 8170282: Enable ALPN parameters to be supplied during the TLS handshake > 8145849: ALPN: getHandshakeApplicationProtocol() always return null > 8158978: ALPN not working when values are set directly on a SSLServerSocket > 8171443: (spec) An ALPN callback function may also ignore ALPN > > RSASSA-PSS: > =========== > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > Reviewed-by: valeriep, weijun, coffeys, pkoppula > > Here are the reviews: > > 1.? ALPN: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > > 2.? RSASSA-PSS: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > > Most of these changes are direct copies of the changesets applied > in JDK 9+, but adjusted for JDK 8u. > > Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were > added to the SUN Provider to support the corresponding truncated > RSASSA-PSS Signatures. > > Thanks, > > Brad > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html > [2] https://www.jcp.org/en/jsr/detail?id=337 > [3] https://bugs.openjdk.java.net/browse/JDK-8230977 > [4] https://bugs.openjdk.java.net/browse/JDK-8233417 > [5] https://bugs.openjdk.java.net/browse/JDK-8230978 > [6] https://bugs.openjdk.java.net/browse/JDK-8233418 > [7] > https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html > > [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ > > From weijun.wang at oracle.com Wed Feb 5 03:14:33 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Feb 2020 11:14:33 +0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: I reviewed the windows/ changes. Looks fine except there is no need to update PRNG.java. Thanks, Max > On Feb 5, 2020, at 7:24 AM, Bradford Wetmore wrote: > > 2. RSASSA-PSS: > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS From felix.yang at huawei.com Wed Feb 5 03:46:34 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 5 Feb 2020 03:46:34 +0000 Subject: [Ping] RE: [8u] RFR 8182397: Race in field updates when creating ArrayKlasses can lead to crash Message-ID: Ping ? Patch still applies to latest jdk8u-dev repo. Copyright years for all files changed to 2020: http://cr.openjdk.java.net/~fyang/8182397-8u-backport/webrev.01/ Thanks, Felix From: Yangfei (Felix) Sent: Friday, November 15, 2019 11:14 AM To: jdk8u-dev at openjdk.java.net Subject: [8u] RFR 8182397: Race in field updates when creating ArrayKlasses can lead to crash Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8182397 http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/e4434fd96f08 Original patch does not apply cleanly to 8u due to line differences and code refactoring. 8u webrev: http://cr.openjdk.java.net/~fyang/8182397-8u-backport/webrev.00/ This updated Copyright years for all files changed. Also removed one line from the newly added testcase in the original patch: @modules java.base/jdk.internal.misc Testing: Run full jtreg test with a x86-64 release build. Newly add test case fail without the patch and pass with the patch. Thanks, Felix From neugens at redhat.com Wed Feb 5 11:39:42 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 05 Feb 2020 12:39:42 +0100 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: On Mon, 2020-02-03 at 20:19 +0100, Aleksey Shipilev wrote: > Hi, > > Not sure why this is RFC, while we actually need to RFR this > integration very carefully, as it > touches many delicate parts of VM. So, treating this as code review > below. Hi Aleksey, As Andrew has noted, this was a RFC because those patches have been already reviewed, that being said, I do really appreciate more eyes, and in fact I should probably have asked directly for a re-review instead. Changes and fixes will need to have their own bug id, but this doesn't matter in this context. Also, the patch is meant to be applied and tested in case we missed something, for example I am unable to test the Windows changes (see below) but of course Azul that helped extensively with the backport did test those, even so, clearly this is the opportunity for everyone to help with extensive testing and shout if anything breaks. > Comments from the cursory look: > > On 1/30/20 12:37 PM, Mario Torre wrote: > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ > > *) I am a bit concerned about the removal/rename of trace->jfr, as it > would probably break some > downstream things, at least for a while. I hope that is the informed > risk taking. Well... That's the main JFR change... unless we really want to go with a difficult to maintain chain of if/defs. It is a risk and we are aware that it may break something but the API is internal and with our knowledge isn't used anywhere, so we decided to go for it. Note that a variant of this patch-set is being already deployed by some companies in their JDKs distributions, so we do have some confidence. Last famous words... > *) Not sure why new jdk8u252-b01 is in .hgtags there, also > THIRD_PARTY_README changes. > > *) makefiles/buildtree.make > make/linux/makefiles/buildtree.make > make/solaris/makefiles/buildtree.make > Indent seems to be missing at new ALWAYS_EXCLUDE_DIRS lines. > > *) make/bsd/makefiles/vm.make: > make/linux/makefiles/vm.make: > make/solaris/makefiles/vm.make: > Indent seems to be missing at new EXCLUDE_JFR_PATHS lines. I'm not sure about those, I think there was something wrong with the export. I created a new clean patch from the repositories: http://cr.openjdk.java.net/~neugens/JDK8u-JFR.01/ > *) make/windows/makefiles/compile.make: > How does this change relate to JFR? > - 349 /D "HS_COMPANY=$(HS_COMPANY)" \ > + 356 /D "HS_COMPANY=$(COMPANY_NAME)" \ > > *) make/windows/makefiles/defs.make: > Ditto, how do the hunks around the VENDOR/COMPANY names relate to > JFR? Those came in because of the changes in vm_version_ext_x86.cpp, which are related to JFR. > *) make/windows/makefiles/vm.make: > Ditto, plus hunks around iphlp_interface.obj, vm_version.obj, > arguments.obj, etc? Those changes are related to this backport: changeset: 50879:d90c3cbf13df user: rwestberg date: Thu Jun 28 15:06:55 2018 +0200 summary: 8003209: JFR events for network utilization This was part of the initial JFR integration in 11. My understanding when we did the review was that this make change was needed to have the build code pick up those files when JFR is enabled. Afaik they are not present in the original backport though, Andrey should be able to clarify on this point. > *) src/os/linux/vm/perfMemory_linux.cpp: > Unclear what new include does there. There are no other changes in > this compilation unit! It > should also be stylistically identical to other include lines, e.g. > have the space after "#". Right, and I'm not sure about this one, the change comes from the first change in the backport but they should be only in: src/hotspot/os/linux/os_perf_linux.cpp I think this one should go away, I'll file a bug to remove it, thanks for spotting it. > *) src/os/posix/vm/os_posix.cpp: > Unclear what ThreadCrashProtection has to do with JFR. The hunk > seems to be coming into jdk/jdk > from JDK-8020701 and rename in JDK-8183925. Neither are listed as > backports. Hmm, thanks for noticing this. The ThreadCrashProtection is used by the JFR backport so this change was ncessary, but I'm now questioning why we didn't backport the rename patch and instead added the ThreadCrashProtection on top of the WatcherThreadCrashProtection. I don't think the change is wrong, but it may cause confusion down the line. I think this needs some clarification from Andrey too. > *) src/share/vm/classfile/classLoader.cpp: > src/share/vm/classfile/systemDictionary.cpp: > Not sure if we need to repackage the instanceKlassHandle here. > Maybe I am missing something? Can you explain what do you see wrong here, I'm not sure I understand? > *) src/share/vm/classfile/systemDictionary.cpp > The "else" branch near find_or_define_instance_class looks dodgy. I > believe it is cleaner to do this: > > // find_or_define_instance_class may return a different > InstanceKlass > if (!k.is_null()) { > k = find_or_define_instance_class(class_name, class_loader, k, > CHECK_(nh)); > } > #if INCLUDE_JFR > if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > ... > } > #endif // INCLUDE_JFR > > *) src/share/vm/compiler/compileBroker.cpp: > Stars are misaligned ;) > 2026 const char *failure_reason = ci_env.failure_reason(); > 2027 const char* retry_message = ci_env.retry_message(); Right, I think those are style thing though, we should probably fix them but in a new bug? > *) > vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp: > It feels safer to stub out implementations like this with > INCLUDE_JFR. I would trust compilers to > inline/eliminate the empty method, but would not trust them to > eliminate all the method body. So it > feels safer to e.g: this makes sense, but it's the current implementation in 11 that came with the backport (and it's still in 11u, I haven't checked the other versions yet). I can file a new bug to fix this in 8u though if you prefer. > *) src/share/vm/gc_implementation/shared/gcTraceSend.cpp > Commented out code, starts with "// XXX" at L236? Right, I think this commented out code should be removed completely. I wasn't much happy about it when we did the round of reviews but assumed we would work on that later and must have forgotten. I'll file a Jira bug for most of those clean-ups you have recommended so we can track them in one go. > *) src/share/vm/opto/node.cpp > New #pragmas related to JFR how? Hmmm, I don't see this in our backport patch... > *) src/share/vm/opto/superword.hpp > "// JVMCI: OrderedPair is moved up", and this relates to JFR how? This change comes from 8136421, but I think it's a mistake we included in this backport. > *) src/share/vm/prims/whitebox.cpp: > src/share/vm/prims/whitebox.hpp: > Additions of WB_EnqueueInitializerForCompilation, > WB_GetHeapAlignment and related rewrite is > related to JFR how? This was necessary for a number of failing tests, see: 8230707: JFR related tests are failing > *) src/share/vm/runtime/biasedLocking.cpp > I would sleep a bit better, if this was protected by INCLUDE_JFR: > > 259 // If requested, return information on which thread held the > bias > 260 if (biased_locker != NULL) { > 261 *biased_locker = biased_thread; > 262 } > 263 > > ...and: > > 502 if (biased_locker != NULL) { > 503 _biased_locker_id = JFR_THREAD_ID(biased_locker); > 504 } Makes sense, I'll include this in the "cleanup" bug then. > *) src/share/vm/runtime/globals.hpp: > Not sure what new default arguments for CommandLineFlags::*at are > for in this changeset. I'm not sure if I understand what you mean, but in this patch JFR is disabled by default. It was agreed during the committer's workshop on Monday to actually have it on by default, so I will file another Jira issue for that. > *) src/share/vm/runtime/safepoint.cpp: > Missing EventSafepointCleanupTask for "rotating gc logs", a recent > addition to 8u. When I apply my most recent export (see above) I do see a EventSafepointCleanupTask for rotating gc logs, is that that you need? > *) src/share/vm/runtime/synchronizer.cpp: > Commented out code: > > 1188 // XXX no such counters. implement? > 1189 // event->set_cause((u1)cause); Yeah, as I said some of those changes were tricky, we decided to mark with comments to work on them later, but this is never a good idea, isn't it? > *) src/share/vm/services/diagnosticArgument.cpp > src/share/vm/services/memTracker.hpp > src/share/vm/utilities/bitMap.inline.hpp > The changes do not seem related to JFR. I forgot about the motivation for this one as it's been more than one year, but I remember I got the same issues during my own attempt at backporting. I believe this had to do with the jfr headers files not being correctly pulled in. Andrey can you please comment on this one? > *) src/share/vm/runtime/mutexLocker.cpp > src/share/vm/runtime/mutexLocker.hpp > > "#ifdef INCLUDE_JFR" is correct, should be "#if INCLUDE_JFR"? We followed the same pattern has the previous define but I think you are right and it should be #if INCLUDE_JFR as we don't want to risk compile this code in case INCLUDE_JFR is defined but false, however now INCLUDE_JFR is completely undefined if we don't --enable-jfr at build time. Nonetheless it should probably be fixed as to avoid future bugs. > > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ > > *) make/CopyIntoClasses.gmk: > Why L95..L99 are commented out? I think this should be reverted or removed completely. > *) make/CreateJars.gmk: > Indents seem foobared. Ouch... thanks for noticing. > *) src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java > How is this change related to JFR? I don't see this in my export, again it may have been caused by the merge patch? > *) test/TEST.groups: > Double new-line? > Will add this to the cleanup. I'll ask the rest of the group working on the JFR to comment on the issues you pointed out I wasn't fully sure about. Thanks for the review! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Wed Feb 5 16:27:04 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 5 Feb 2020 16:27:04 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: On 04/02/2020 23:24, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.? The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > Thanks. Sorry for not getting to this just yet (work on 7u taking longer than expected), but I would still like to take a look before it goes in. I'll try and do that today. Thanks for your patience, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From valerie.peng at oracle.com Wed Feb 5 22:31:14 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 5 Feb 2020 14:31:14 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> References: <78a077db-f2ef-c6cf-8fb0-fa07909c191b@oracle.com> Message-ID: <4857368e-2f31-3dfe-94ae-a0a34a6d6cb3@oracle.com> Hi Brad, src/windows/classes/sun/security/mscapi/PRNG.java: take this file off the list of changes as it only contains copyright update. Rest looks good to me. Thanks, Valerie On 2/4/2020 5:08 PM, Xuelei Fan wrote: > > 1.? ALPN: > > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > I reviewed this part, which look good to me. > > Thanks, > Xuelei > > On 2/4/2020 3:24 PM, Bradford Wetmore wrote: >> I added a simple PSS 32-bit windows crash fix, which was previously >> reviewed in security-dev earlier today [0]. >> >> ???? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> >> The PSS webrev is now at version .01. >> >> Otherwise, everything is identical from last week's request below.? >> The ALPN remains at version .00. >> >> [0] >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html >> >> >> ---begin--- >> >> Good morning/afternoon/evening/night, >> >> As announced on jdk8u-dev[1], there is a Maintenance Release in progress >> for Java SE 8 (i.e. JSR 337) [2] to include two security features >> important for TLS 1.3: >> >> 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] >> 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme >> (RSASSA-PSS) [5][6] >> >> As mentioned in [1], if it wasn't too much work then we would like to >> contribute the changes required by this MR to the next appropriate >> OpenJDK 8 release, most likely 8u252. >> >> Now that the MR3 balloting successfully concluded last night, I'd >> like to make that happen, and move the code into review. >> >> The code is essentially what was reviewed for 8u41[7][8] and >> internally for what we expect to be in Oracle's 8u251 JDK, except the >> code in this review is based on the current JDK 8u workspace.? We >> also included code to allow the Windows platform to use PSS natively. >> >> The specific bugs/backports (requested by the JDK8u maintainers) follow: >> >> ALPN: >> ===== >> 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension (Java SE 8) >> 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation >> Extension >> 8170282: Enable ALPN parameters to be supplied during the TLS handshake >> 8145849: ALPN: getHandshakeApplicationProtocol() always return null >> 8158978: ALPN not working when values are set directly on a >> SSLServerSocket >> 8171443: (spec) An ALPN callback function may also ignore ALPN >> >> RSASSA-PSS: >> =========== >> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >> 8175029: StackOverflowError in X509CRL and >> X509Certificate.verify(PublicKey, Provider) >> 8146293: Add support for RSASSA-PSS Signature algorithm >> 8205445: Add RSASSA-PSS Signature support to SunMSCAPI >> 8205720: KeyFactory#getKeySpec and translateKey throws >> NullPointerException with Invalid key >> 8206171: Signature#getParameters for RSASSA-PSS throws >> ProviderException when not initialized >> 8213009: Refactoring existing SunMSCAPI classes >> 8213010: Supporting keys created with certmgr.exe >> 8214096: sun.security.util.SignatureUtil passes null parameter, so >> JCE validation fails >> 8215694: keytool cannot generate RSASSA-PSS certificates >> 8221407: Windows 32bit build error in libsunmscapi/security.cpp >> 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange >> 8223003: SunMSCAPI keys are not cleaned up >> 8223063: Support CNG RSA keys >> 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with >> RSASSA-PSS support >> 8225180: SignedObject with invalid Key not throwing the >> InvalidKeyException in Windows >> 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as >> AlgorithmId >> Reviewed-by: valeriep, weijun, coffeys, pkoppula >> >> Here are the reviews: >> >> 1.? ALPN: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN >> >> 2.? RSASSA-PSS: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS >> >> Most of these changes are direct copies of the changesets applied >> in JDK 9+, but adjusted for JDK 8u. >> >> Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were >> added to the SUN Provider to support the corresponding truncated >> RSASSA-PSS Signatures. >> >> Thanks, >> >> Brad >> >> [1] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html >> [2] https://www.jcp.org/en/jsr/detail?id=337 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230977 >> [4] https://bugs.openjdk.java.net/browse/JDK-8233417 >> [5] https://bugs.openjdk.java.net/browse/JDK-8230978 >> [6] https://bugs.openjdk.java.net/browse/JDK-8233418 >> [7] >> https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html >> >> [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ >> >> From bradford.wetmore at oracle.com Thu Feb 6 00:24:58 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 5 Feb 2020 16:24:58 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: <0e689ca2-c2c6-9a04-b2f2-3875816bd55f@oracle.com> Thanks, I'll update it. Brad On 2/4/2020 7:14 PM, Weijun Wang wrote: > I reviewed the windows/ changes. Looks fine except there is no need to update PRNG.java. > > Thanks, > Max > >> On Feb 5, 2020, at 7:24 AM, Bradford Wetmore wrote: >> >> 2. RSASSA-PSS: >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > From gnu.andrew at redhat.com Thu Feb 6 03:03:22 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 6 Feb 2020 03:03:22 +0000 Subject: OpenJDK 8u252-b02 EA Released Message-ID: <7c0d52a4-6300-3d67-18fa-3465c0a695b1@redhat.com> I've made available an early access source bundle for 8u252, based on the tag jdk8u252-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u252-b02-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u252-b02-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 7912b8595a03101f969492eb29d22193fffc5022b6a42dc38c5d7c11f7274aa5 openjdk8u252-b02-ea.tar.xz 4803903ecde749ef510da7705b872ae38dc229381a3e274f78f659fb67c058e8 openjdk8u252-b02-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u252-b02-ea.sha256 Changes in 8u252-b02: - S7143743: Potential memory leak with zip provider - S8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out - S8143849: Integrate Marlin renderer per JEP 265 - S8146792: Predicate moved after partial peel may lead to broken graph - S8193255: Root Certificates should be stored in text format and assembled at build time - S8232154: Update Mesa 3-D Headers to version 19.2.1 - S8233995: java.vm.vendor (and potentially other properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8 - S8235142: JDK-8193255 backport broke bootstrap with JDK 10 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 6 03:08:26 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 6 Feb 2020 03:08:26 +0000 Subject: RFR: [8u] 8229767: Typo in java.security: Sasl.createClient and Sasl.createServer Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8229767 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8229767/webrev.01/ This is a simple comment correction to follow JDK-8200400 which has now been pushed to 8u. The change remains the same as in OpenJDK 11, but needs to be duplicated across multiple files, due to the use of java.security in OpenJDK 11, but java.security-${OS} in OpenJDK 8u. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 6 05:40:57 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 6 Feb 2020 05:40:57 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: Message-ID: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> On 04/02/2020 23:24, Bradford Wetmore wrote: > I added a simple PSS 32-bit windows crash fix, which was previously > reviewed in security-dev earlier today [0]. > > ??? 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > > The PSS webrev is now at version .01. > > Otherwise, everything is identical from last week's request below.? The > ALPN remains at version .00. > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021203.html > > > ---begin--- > > Good morning/afternoon/evening/night, > > As announced on jdk8u-dev[1], there is a Maintenance Release in progress > for Java SE 8 (i.e. JSR 337) [2] to include two security features > important for TLS 1.3: > > 1.? Application-Layer Protocol Negotiation (ALPN) [3][4] > 2.? RSA Signature Scheme with Appendix: Probabilistic Signature Scheme > (RSASSA-PSS) [5][6] > > As mentioned in [1], if it wasn't too much work then we would like to > contribute the changes required by this MR to the next appropriate > OpenJDK 8 release, most likely 8u252. > > Now that the MR3 balloting successfully concluded last night, I'd like > to make that happen, and move the code into review. > > The code is essentially what was reviewed for 8u41[7][8] and internally > for what we expect to be in Oracle's 8u251 JDK, except the code in this > review is based on the current JDK 8u workspace.? We also included code > to allow the Windows platform to use PSS natively. > > The specific bugs/backports (requested by the JDK8u maintainers) follow: > > ALPN: > ===== > 8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension (Java SE 8) > 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation > Extension > 8170282: Enable ALPN parameters to be supplied during the TLS handshake > 8145849: ALPN: getHandshakeApplicationProtocol() always return null > 8158978: ALPN not working when values are set directly on a SSLServerSocket > 8171443: (spec) An ALPN callback function may also ignore ALPN > > RSASSA-PSS: > =========== > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > Reviewed-by: valeriep, weijun, coffeys, pkoppula > > Here are the reviews: > > 1.? ALPN: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/ALPN > > 2.? RSASSA-PSS: > ???? http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS > > Most of these changes are direct copies of the changesets applied > in JDK 9+, but adjusted for JDK 8u. > > Also, truncated MessageDigests (i.e. SHA-512/224, SHA-512/256) were > added to the SUN Provider to support the corresponding truncated > RSASSA-PSS Signatures. > > Thanks, > > Brad > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010573.html > [2] https://www.jcp.org/en/jsr/detail?id=337 > [3] https://bugs.openjdk.java.net/browse/JDK-8230977 > [4] https://bugs.openjdk.java.net/browse/JDK-8233417 > [5] https://bugs.openjdk.java.net/browse/JDK-8230978 > [6] https://bugs.openjdk.java.net/browse/JDK-8233418 > [7] > https://mail.openjdk.java.net/pipermail/security-dev/2019-November/020900.html > > [8] http://hg.openjdk.java.net/jdk8u/jdk8u41/ > > Hi Brad, First of all, thanks again for posting these patches and also for the comprehensive list of issues for both of them. They pretty much matched up with what I saw when reviewing the patches. The ALPN one looks pretty clean. My only concern there is the use of "@since 8". Should this not be a reference to the maintenance release, as these methods were not part of 8 at GA? Same applies to the usage in the second patch too. With the RSA-PSS patch, it's hard to tell what's going on with the MSCAPI code, because they appear as new files in the patch. Why was it necessary to bring in JDK-8213009? I don't see an obvious reason for this. I know from the fix request on that bug for 11u that it's a dependency of 8213010, but again, it's not obvious why that's required here either. Some more details on why some of the less obvious bugs are required would be helpful here. If the refactoring is necessary, a Git-style patch which shows the moves as renames (hg diff -g) would help, so we can see what is actually being changed in these files. As you say, the RSA-PSS patch brings in truncated MessageDigests which are part of "8051408: NIST SP 800-90A SecureRandom implementations". It would be good if the summary field could be used to say "Contains truncated MessageDigests from JDK-8051408", so that it then shows up if someone is considering 8051408 at a later date. Otherwise, looks good. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens at redhat.com Thu Feb 6 10:40:54 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 6 Feb 2020 11:40:54 +0100 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: I created two bugs for now: https://bugs.openjdk.java.net/browse/JDK-8238589 https://bugs.openjdk.java.net/browse/JDK-8238590 The first is to track the polishing efforts (only cosmetic, I will file separate issues for each bug we identify that has is functional rather than cosmetic). The second is to pass --enable-jfr by default (in fact, turn it into a --disable-jfr flag). Cheers, Mario On Wed, Feb 5, 2020 at 12:39 PM Mario Torre wrote: > > On Mon, 2020-02-03 at 20:19 +0100, Aleksey Shipilev wrote: > > Hi, > > > > Not sure why this is RFC, while we actually need to RFR this > > integration very carefully, as it > > touches many delicate parts of VM. So, treating this as code review > > below. > > Hi Aleksey, > > As Andrew has noted, this was a RFC because those patches have been > already reviewed, that being said, I do really appreciate more eyes, > and in fact I should probably have asked directly for a re-review > instead. Changes and fixes will need to have their own bug id, but this > doesn't matter in this context. > > Also, the patch is meant to be applied and tested in case we missed > something, for example I am unable to test the Windows changes (see > below) but of course Azul that helped extensively with the backport did > test those, even so, clearly this is the opportunity for everyone to > help with extensive testing and shout if anything breaks. > > > Comments from the cursory look: > > > > On 1/30/20 12:37 PM, Mario Torre wrote: > > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ > > > > *) I am a bit concerned about the removal/rename of trace->jfr, as it > > would probably break some > > downstream things, at least for a while. I hope that is the informed > > risk taking. > > Well... That's the main JFR change... unless we really want to go with > a difficult to maintain chain of if/defs. > > It is a risk and we are aware that it may break something but the API > is internal and with our knowledge isn't used anywhere, so we decided > to go for it. > > Note that a variant of this patch-set is being already deployed by some > companies in their JDKs distributions, so we do have some confidence. > Last famous words... > > > *) Not sure why new jdk8u252-b01 is in .hgtags there, also > > THIRD_PARTY_README changes. > > > > *) makefiles/buildtree.make > > make/linux/makefiles/buildtree.make > > make/solaris/makefiles/buildtree.make > > Indent seems to be missing at new ALWAYS_EXCLUDE_DIRS lines. > > > > *) make/bsd/makefiles/vm.make: > > make/linux/makefiles/vm.make: > > make/solaris/makefiles/vm.make: > > Indent seems to be missing at new EXCLUDE_JFR_PATHS lines. > > I'm not sure about those, I think there was something wrong with the > export. I created a new clean patch from the repositories: > > http://cr.openjdk.java.net/~neugens/JDK8u-JFR.01/ > > > *) make/windows/makefiles/compile.make: > > How does this change relate to JFR? > > - 349 /D "HS_COMPANY=$(HS_COMPANY)" \ > > + 356 /D "HS_COMPANY=$(COMPANY_NAME)" \ > > > > *) make/windows/makefiles/defs.make: > > Ditto, how do the hunks around the VENDOR/COMPANY names relate to > > JFR? > > Those came in because of the changes in vm_version_ext_x86.cpp, which > are related to JFR. > > > *) make/windows/makefiles/vm.make: > > Ditto, plus hunks around iphlp_interface.obj, vm_version.obj, > > arguments.obj, etc? > > Those changes are related to this backport: > > changeset: 50879:d90c3cbf13df > user: rwestberg > date: Thu Jun 28 15:06:55 2018 +0200 > summary: 8003209: JFR events for network utilization > > This was part of the initial JFR integration in 11. My understanding > when we did the review was that this make change was needed to have the > build code pick up those files when JFR is enabled. Afaik they are not > present in the original backport though, Andrey should be able to > clarify on this point. > > > *) src/os/linux/vm/perfMemory_linux.cpp: > > Unclear what new include does there. There are no other changes in > > this compilation unit! It > > should also be stylistically identical to other include lines, e.g. > > have the space after "#". > > Right, and I'm not sure about this one, the change comes from the first > change in the backport but they should be only in: > > src/hotspot/os/linux/os_perf_linux.cpp > > I think this one should go away, I'll file a bug to remove it, thanks > for spotting it. > > > *) src/os/posix/vm/os_posix.cpp: > > Unclear what ThreadCrashProtection has to do with JFR. The hunk > > seems to be coming into jdk/jdk > > from JDK-8020701 and rename in JDK-8183925. Neither are listed as > > backports. > > Hmm, thanks for noticing this. The ThreadCrashProtection is used by the > JFR backport so this change was ncessary, but I'm now questioning why > we didn't backport the rename patch and instead added the > ThreadCrashProtection on top of the WatcherThreadCrashProtection. > > I don't think the change is wrong, but it may cause confusion down the > line. > > I think this needs some clarification from Andrey too. > > > *) src/share/vm/classfile/classLoader.cpp: > > src/share/vm/classfile/systemDictionary.cpp: > > Not sure if we need to repackage the instanceKlassHandle here. > > Maybe I am missing something? > > Can you explain what do you see wrong here, I'm not sure I understand? > > > *) src/share/vm/classfile/systemDictionary.cpp > > The "else" branch near find_or_define_instance_class looks dodgy. I > > believe it is cleaner to do this: > > > > // find_or_define_instance_class may return a different > > InstanceKlass > > if (!k.is_null()) { > > k = find_or_define_instance_class(class_name, class_loader, k, > > CHECK_(nh)); > > } > > #if INCLUDE_JFR > > if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > > ... > > } > > #endif // INCLUDE_JFR > > > > *) src/share/vm/compiler/compileBroker.cpp: > > Stars are misaligned ;) > > 2026 const char *failure_reason = ci_env.failure_reason(); > > 2027 const char* retry_message = ci_env.retry_message(); > > Right, I think those are style thing though, we should probably fix > them but in a new bug? > > > *) > > vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp: > > It feels safer to stub out implementations like this with > > INCLUDE_JFR. I would trust compilers to > > inline/eliminate the empty method, but would not trust them to > > eliminate all the method body. So it > > feels safer to e.g: > > this makes sense, but it's the current implementation in 11 that came > with the backport (and it's still in 11u, I haven't checked the other > versions yet). I can file a new bug to fix this in 8u though if you > prefer. > > > *) src/share/vm/gc_implementation/shared/gcTraceSend.cpp > > Commented out code, starts with "// XXX" at L236? > > Right, I think this commented out code should be removed completely. I > wasn't much happy about it when we did the round of reviews but assumed > we would work on that later and must have forgotten. I'll file a Jira > bug for most of those clean-ups you have recommended so we can track > them in one go. > > > *) src/share/vm/opto/node.cpp > > New #pragmas related to JFR how? > > Hmmm, I don't see this in our backport patch... > > > *) src/share/vm/opto/superword.hpp > > "// JVMCI: OrderedPair is moved up", and this relates to JFR how? > > This change comes from 8136421, but I think it's a mistake we included > in this backport. > > > *) src/share/vm/prims/whitebox.cpp: > > src/share/vm/prims/whitebox.hpp: > > Additions of WB_EnqueueInitializerForCompilation, > > WB_GetHeapAlignment and related rewrite is > > related to JFR how? > > This was necessary for a number of failing tests, see: > > 8230707: JFR related tests are failing > > > *) src/share/vm/runtime/biasedLocking.cpp > > I would sleep a bit better, if this was protected by INCLUDE_JFR: > > > > 259 // If requested, return information on which thread held the > > bias > > 260 if (biased_locker != NULL) { > > 261 *biased_locker = biased_thread; > > 262 } > > 263 > > > > ...and: > > > > 502 if (biased_locker != NULL) { > > 503 _biased_locker_id = JFR_THREAD_ID(biased_locker); > > 504 } > > > Makes sense, I'll include this in the "cleanup" bug then. > > > *) src/share/vm/runtime/globals.hpp: > > Not sure what new default arguments for CommandLineFlags::*at are > > for in this changeset. > > I'm not sure if I understand what you mean, but in this patch JFR is > disabled by default. It was agreed during the committer's workshop on > Monday to actually have it on by default, so I will file another Jira > issue for that. > > > *) src/share/vm/runtime/safepoint.cpp: > > Missing EventSafepointCleanupTask for "rotating gc logs", a recent > > addition to 8u. > > When I apply my most recent export (see above) I do see a > EventSafepointCleanupTask for rotating gc logs, is that that you need? > > > *) src/share/vm/runtime/synchronizer.cpp: > > Commented out code: > > > > 1188 // XXX no such counters. implement? > > 1189 // event->set_cause((u1)cause); > > Yeah, as I said some of those changes were tricky, we decided to mark > with comments to work on them later, but this is never a good idea, > isn't it? > > > *) src/share/vm/services/diagnosticArgument.cpp > > src/share/vm/services/memTracker.hpp > > src/share/vm/utilities/bitMap.inline.hpp > > The changes do not seem related to JFR. > > I forgot about the motivation for this one as it's been more than one > year, but I remember I got the same issues during my own attempt at > backporting. I believe this had to do with the jfr headers files not > being correctly pulled in. Andrey can you please comment on this one? > > > *) src/share/vm/runtime/mutexLocker.cpp > > src/share/vm/runtime/mutexLocker.hpp > > > > "#ifdef INCLUDE_JFR" is correct, should be "#if INCLUDE_JFR"? > > We followed the same pattern has the previous define but I think you > are right and it should be #if INCLUDE_JFR as we don't want to risk > compile this code in case INCLUDE_JFR is defined but false, however now > INCLUDE_JFR is completely undefined if we don't --enable-jfr at build > time. Nonetheless it should probably be fixed as to avoid future bugs. > > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ > > > > *) make/CopyIntoClasses.gmk: > > Why L95..L99 are commented out? > > I think this should be reverted or removed completely. > > > *) make/CreateJars.gmk: > > Indents seem foobared. > > Ouch... thanks for noticing. > > > *) src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java > > How is this change related to JFR? > > I don't see this in my export, again it may have been caused by the > merge patch? > > > *) test/TEST.groups: > > Double new-line? > > > > Will add this to the cleanup. > > I'll ask the rest of the group working on the JFR to comment on the > issues you pointed out I wasn't fully sure about. > > Thanks for the review! > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey at azul.com Thu Feb 6 15:14:24 2020 From: andrey at azul.com (Andrey Petushkov) Date: Thu, 6 Feb 2020 15:14:24 +0000 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: Hi Aleksey, All, Thank you so much for such thorough review! Please see some comments and answers inline On 05.02.2020 14:39, Mario Torre wrote: > On Mon, 2020-02-03 at 20:19 +0100, Aleksey Shipilev wrote: >> Hi, >> >> Not sure why this is RFC, while we actually need to RFR this >> integration very carefully, as it >> touches many delicate parts of VM. So, treating this as code review >> below. > Hi Aleksey, > > As Andrew has noted, this was a RFC because those patches have been > already reviewed, that being said, I do really appreciate more eyes, > and in fact I should probably have asked directly for a re-review > instead. Changes and fixes will need to have their own bug id, but this > doesn't matter in this context. > > Also, the patch is meant to be applied and tested in case we missed > something, for example I am unable to test the Windows changes (see > below) but of course Azul that helped extensively with the backport did > test those, even so, clearly this is the opportunity for everyone to > help with extensive testing and shout if anything breaks. > >> Comments from the cursory look: >> >> On 1/30/20 12:37 PM, Mario Torre wrote: >>> https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ >> *) I am a bit concerned about the removal/rename of trace->jfr, as it >> would probably break some >> downstream things, at least for a while. I hope that is the informed >> risk taking. > Well... That's the main JFR change... unless we really want to go with > a difficult to maintain chain of if/defs. > > It is a risk and we are aware that it may break something but the API > is internal and with our knowledge isn't used anywhere, so we decided > to go for it. > > Note that a variant of this patch-set is being already deployed by some > companies in their JDKs distributions, so we do have some confidence. > Last famous words... > >> *) Not sure why new jdk8u252-b01 is in .hgtags there, also >> THIRD_PARTY_README changes. >> >> *) makefiles/buildtree.make >> make/linux/makefiles/buildtree.make >> make/solaris/makefiles/buildtree.make >> Indent seems to be missing at new ALWAYS_EXCLUDE_DIRS lines. >> >> *) make/bsd/makefiles/vm.make: >> make/linux/makefiles/vm.make: >> make/solaris/makefiles/vm.make: >> Indent seems to be missing at new EXCLUDE_JFR_PATHS lines. > I'm not sure about those, I think there was something wrong with the > export. I created a new clean patch from the repositories: > > http://cr.openjdk.java.net/~neugens/JDK8u-JFR.01/ > >> *) make/windows/makefiles/compile.make: >> How does this change relate to JFR? >> - 349 /D "HS_COMPANY=$(HS_COMPANY)" \ >> + 356 /D "HS_COMPANY=$(COMPANY_NAME)" \ >> >> *) make/windows/makefiles/defs.make: >> Ditto, how do the hunks around the VENDOR/COMPANY names relate to >> JFR? > Those came in because of the changes in vm_version_ext_x86.cpp, which > are related to JFR. > >> *) make/windows/makefiles/vm.make: >> Ditto, plus hunks around iphlp_interface.obj, vm_version.obj, >> arguments.obj, etc? > Those changes are related to this backport: > > changeset: 50879:d90c3cbf13df > user: rwestberg > date: Thu Jun 28 15:06:55 2018 +0200 > summary: 8003209: JFR events for network utilization > > This was part of the initial JFR integration in 11. My understanding > when we did the review was that this make change was needed to have the > build code pick up those files when JFR is enabled. Afaik they are not > present in the original backport though, Andrey should be able to > clarify on this point. should not be there. anyway these changes are not present in the updated patch >> *) src/os/linux/vm/perfMemory_linux.cpp: >> Unclear what new include does there. There are no other changes in >> this compilation unit! It >> should also be stylistically identical to other include lines, e.g. >> have the space after "#". > Right, and I'm not sure about this one, the change comes from the first > change in the backport but they should be only in: > > src/hotspot/os/linux/os_perf_linux.cpp > > I think this one should go away, I'll file a bug to remove it, thanks > for spotting it. right, this is bug induced by going back and forth on having 8202353 backported as part of initial JFR backport batch. should be removed > >> *) src/os/posix/vm/os_posix.cpp: >> Unclear what ThreadCrashProtection has to do with JFR. The hunk >> seems to be coming into jdk/jdk >> from JDK-8020701 and rename in JDK-8183925. Neither are listed as >> backports. > Hmm, thanks for noticing this. The ThreadCrashProtection is used by the > JFR backport so this change was ncessary, but I'm now questioning why > we didn't backport the rename patch and instead added the > ThreadCrashProtection on top of the WatcherThreadCrashProtection. > > I don't think the change is wrong, but it may cause confusion down the > line. > > I think this needs some clarification from Andrey too. yes, this was strategical mistake made during initial backport. anyway, the work on doing this the right way is almost complete ([1]) > >> *) src/share/vm/classfile/classLoader.cpp: >> src/share/vm/classfile/systemDictionary.cpp: >> Not sure if we need to repackage the instanceKlassHandle here. >> Maybe I am missing something? > Can you explain what do you see wrong here, I'm not sure I understand? ON_CLASS_CREATION modifies the value of it's InstanceKlass* argument because JFR rewrites the class itself if it's subject to this (it happens for all JFR event classes). see jfrEventClassTransformer.cpp for more details >> *) src/share/vm/classfile/systemDictionary.cpp >> The "else" branch near find_or_define_instance_class looks dodgy. I >> believe it is cleaner to do this: >> >> // find_or_define_instance_class may return a different >> InstanceKlass >> if (!k.is_null()) { >> k = find_or_define_instance_class(class_name, class_loader, k, >> CHECK_(nh)); >> } >> #if INCLUDE_JFR >> if (k.is_null() && (class_name == jfr_event_handler_proxy)) { >> ... >> } >> #endif // INCLUDE_JFR >> >> *) src/share/vm/compiler/compileBroker.cpp: >> Stars are misaligned ;) >> 2026 const char *failure_reason = ci_env.failure_reason(); >> 2027 const char* retry_message = ci_env.retry_message(); > Right, I think those are style thing though, we should probably fix > them but in a new bug? > >> *) >> vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp: >> It feels safer to stub out implementations like this with >> INCLUDE_JFR. I would trust compilers to >> inline/eliminate the empty method, but would not trust them to >> eliminate all the method body. So it >> feels safer to e.g: > this makes sense, but it's the current implementation in 11 that came > with the backport (and it's still in 11u, I haven't checked the other > versions yet). I can file a new bug to fix this in 8u though if you > prefer. > >> *) src/share/vm/gc_implementation/shared/gcTraceSend.cpp >> Commented out code, starts with "// XXX" at L236? > Right, I think this commented out code should be removed completely. I > wasn't much happy about it when we did the round of reviews but assumed > we would work on that later and must have forgotten. I'll file a Jira > bug for most of those clean-ups you have recommended so we can track > them in one go. > >> *) src/share/vm/opto/node.cpp >> New #pragmas related to JFR how? > Hmmm, I don't see this in our backport patch... > >> *) src/share/vm/opto/superword.hpp >> "// JVMCI: OrderedPair is moved up", and this relates to JFR how? > This change comes from 8136421, but I think it's a mistake we included > in this backport. right, definitely a bug. sorry for that > >> *) src/share/vm/prims/whitebox.cpp: >> src/share/vm/prims/whitebox.hpp: >> Additions of WB_EnqueueInitializerForCompilation, >> WB_GetHeapAlignment and related rewrite is >> related to JFR how? > This was necessary for a number of failing tests, see: > > 8230707: JFR related tests are failing > >> *) src/share/vm/runtime/biasedLocking.cpp >> I would sleep a bit better, if this was protected by INCLUDE_JFR: >> >> 259 // If requested, return information on which thread held the >> bias >> 260 if (biased_locker != NULL) { >> 261 *biased_locker = biased_thread; >> 262 } >> 263 >> >> ...and: >> >> 502 if (biased_locker != NULL) { >> 503 _biased_locker_id = JFR_THREAD_ID(biased_locker); >> 504 } > > Makes sense, I'll include this in the "cleanup" bug then. > >> *) src/share/vm/runtime/globals.hpp: >> Not sure what new default arguments for CommandLineFlags::*at are >> for in this changeset. > I'm not sure if I understand what you mean, but in this patch JFR is > disabled by default. It was agreed during the committer's workshop on > Monday to actually have it on by default, so I will file another Jira > issue for that. > >> *) src/share/vm/runtime/safepoint.cpp: >> Missing EventSafepointCleanupTask for "rotating gc logs", a recent >> addition to 8u. > When I apply my most recent export (see above) I do see a > EventSafepointCleanupTask for rotating gc logs, is that that you need? > >> *) src/share/vm/runtime/synchronizer.cpp: >> Commented out code: >> >> 1188 // XXX no such counters. implement? >> 1189 // event->set_cause((u1)cause); > Yeah, as I said some of those changes were tricky, we decided to mark > with comments to work on them later, but this is never a good idea, > isn't it? > >> *) src/share/vm/services/diagnosticArgument.cpp fix for failed JFR jtreg test, despite the bug is in non-JFR code >> src/share/vm/services/memTracker.hpp >> src/share/vm/utilities/bitMap.inline.hpp these changes are needed for the build with JFR to succeed. maybe some of upstream changesets could have been ported to make it clearer, but I really doubt one would like to see all accompanying luggage >> The changes do not seem related to JFR. > I forgot about the motivation for this one as it's been more than one > year, but I remember I got the same issues during my own attempt at > backporting. I believe this had to do with the jfr headers files not > being correctly pulled in. Andrey can you please comment on this one? > >> *) src/share/vm/runtime/mutexLocker.cpp >> src/share/vm/runtime/mutexLocker.hpp >> >> "#ifdef INCLUDE_JFR" is correct, should be "#if INCLUDE_JFR"? > We followed the same pattern has the previous define but I think you > are right and it should be #if INCLUDE_JFR as we don't want to risk > compile this code in case INCLUDE_JFR is defined but false, however now > INCLUDE_JFR is completely undefined if we don't --enable-jfr at build > time. Nonetheless it should probably be fixed as to avoid future bugs. yes, should be #if > >>> https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ >> *) make/CopyIntoClasses.gmk: >> Why L95..L99 are commented out? > I think this should be reverted or removed completely. right. and given that we are to remove "trace" things it's likely removal has more sense >> *) make/CreateJars.gmk: >> Indents seem foobared. > Ouch... thanks for noticing. > >> *) src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java >> How is this change related to JFR? > I don't see this in my export, again it may have been caused by the > merge patch? > >> *) test/TEST.groups: >> Double new-line? >> > Will add this to the cleanup. > > I'll ask the rest of the group working on the JFR to comment on the > issues you pointed out I wasn't fully sure about. > > Thanks for the review! > > Cheers, > Mario Regards, Andrey [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010819.html From hohensee at amazon.com Thu Feb 6 15:55:17 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 Feb 2020 15:55:17 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: Reviving this one. Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592 Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/ Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp. Thanks, Paul ?On 8/30/19, 9:31 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Thanks, Andrew. I saw you got review approval by Severin. How about we move forward? I am good if you apply your patch for JDK-8062808. Could you also take care of 'perfData.hpp'? we missed it. Thanks, --lx On 8/30/19, 8:53 AM, "Andrew John Hughes" wrote: On 28/08/2019 22:00, Liu, Xin wrote: > Hi, > > > I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? > > webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ > > > It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. > > > I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. > > > thanks, > > --lx > I already have a backport of this, which I intend to post once JDK-8141570 is in; see [0]. Doing this beforehand will break the Zero build. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010100.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Thu Feb 6 16:03:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 6 Feb 2020 16:03:33 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: Bad webrev. Good one at http://cr.openjdk.java.net/~phh/8062808/webrev.8u.01/. ?On 2/6/20, 7:57 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Reviving this one. Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592 Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/ Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp. Thanks, Paul On 8/30/19, 9:31 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Thanks, Andrew. I saw you got review approval by Severin. How about we move forward? I am good if you apply your patch for JDK-8062808. Could you also take care of 'perfData.hpp'? we missed it. Thanks, --lx On 8/30/19, 8:53 AM, "Andrew John Hughes" wrote: On 28/08/2019 22:00, Liu, Xin wrote: > Hi, > > > I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? > > webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ > > > It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. > > > I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. > > > thanks, > > --lx > I already have a backport of this, which I intend to post once JDK-8141570 is in; see [0]. Doing this beforehand will break the Zero build. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010100.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Feb 7 18:10:49 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 7 Feb 2020 18:10:49 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: On 06/02/2020 15:55, Hohensee, Paul wrote: > Reviving this one. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592 > Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/ > > Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp. > > Thanks, > Paul > Yeah, I've been holding off on this, because it affects downstream out-of-tree-ports and I was hoping to get the AArch64 port in first. However, I think that's now looking like something for 8u262. I also appreciated, during the recent release processes, that neither 8u & 11u build with -Werror for me as they stand upstream, so I would like to see this resolved. I'll take a look at the patch on Monday. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From bradford.wetmore at oracle.com Sat Feb 8 00:10:53 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 7 Feb 2020 16:10:53 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: On 2/5/2020 9:40 PM, Andrew John Hughes wrote:> First of all, thanks again for posting these patches and also for the > comprehensive list of issues for both of them. They pretty much matched > up with what I saw when reviewing the patches Great. > The ALPN one looks pretty clean. My only concern there is the use of > "@since 8". Should this not be a reference to the maintenance release, > as these methods were not part of 8 at GA? Same applies to the usage in > the second patch too. I originally had this as "@since 8 MR 3" but during internal review it was requested to use @since 8 instead. This is what was presented/voted during the MR phase. > With the RSA-PSS patch, it's hard to tell what's going on with the > MSCAPI code, because they appear as new files in the patch. Why was it > necessary to bring in JDK-8213009? I don't see an obvious reason for > this. JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code layout, and to a lesser degree to better support Windows-native PSS calls using CNG (MS Windows Crypto Next Generation). The SunMSCAPI provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG calls when CAPI couldn't support everything needed. The SunMSCAPI changes that followed would take significant effort to extricate these reorganization changes when backporting later changes (e.g. jdk/jdk). We could have forward ported/merged the 8u41 code into OpenJDK 8, but unfortunately I haven't been given a lot of cycles for OpenJDK code. > dependency of 8213010, but again, it's not obvious why that's required > here either. Some more details on why some of the less obvious bugs are > required would be helpful here. Ok, I've added details to a comment in JDK-8230978. > If the refactoring is necessary, a > Git-style patch which shows the moves as renames (hg diff -g) would > help, so we can see what is actually being changed in these files. I'm a bit confused, isn't the webrev already showing this: http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ ---begin--- ...deleted... * src/windows/classes/sun/security/mscapi/CKey.java* /(was src/windows/classes/sun/security/mscapi/Key.java)/ ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ ...deleted... * src/windows/classes/sun/security/mscapi/CSignature.java /(was src/windows/classes/sun/security/mscapi/RSASignature.java)/ ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ ---end--- Looking at the index.html and subsequent "Frame" for this file, I can see both the rename and the old/new code side-by-side. > As you say, the RSA-PSS patch brings in truncated MessageDigests which > are part of "8051408: NIST SP 800-90A SecureRandom implementations". It > would be good if the summary field could be used to say "Contains > truncated MessageDigests from JDK-8051408", so that it then shows up if > someone is considering 8051408 at a later date There are several comments to make which won't fit in the summary field which is supposed to only be one short line [0]. Instead, I have added several items into the comment for JDK-8230978, which is the main umbrella bug for the PSS work, and I will add: Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and OpenJDK 8u to the changeset, which currently reads: ---begin--- 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) 8146293: Add support for RSASSA-PSS Signature algorithm 8205445: Add RSASSA-PSS Signature support to SunMSCAPI 8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized 8213009: Refactoring existing SunMSCAPI classes 8213010: Supporting keys created with certmgr.exe 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails 8215694: keytool cannot generate RSASSA-PSS certificates 8221407: Windows 32bit build error in libsunmscapi/security.cpp 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange 8223003: SunMSCAPI keys are not cleaned up 8223063: Support CNG RSA keys 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support 8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and OpenJDK 8u Reviewed-by: valeriep, weijun, coffeys, pkoppula ---end--- Did you want me to add you as a reviewer? > Otherwise, looks good. > > Thanks, Thanks, Brad [0] https://openjdk.java.net/guide/producingChangeset.html From bourges.laurent at gmail.com Mon Feb 10 08:48:59 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 10 Feb 2020 09:48:59 +0100 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> Message-ID: Hi David & Paul, Could you help me in preparing & reviewing patches (20 remain to be integrated in 8u) to be faster ? Most of them apply cleanly so it consists in adding jdk8u-fix-request, wait for yes then push in 8u-dev. 2nd pending request: https://bugs.openjdk.java.net/browse/JDK-8145055 Only few large patches will need a RFR for 8u. Cheers, Laurent Le ven. 8 nov. 2019 ? 17:13, Hohensee, Paul a ?crit : > Thank you, Laurent. > > > > Paul > > > > *From: *Laurent Bourg?s > *Date: *Tuesday, November 5, 2019 at 2:41 AM > *To: *"Hohensee, Paul" > *Cc: *"Alvarez, David" , Martijn Verburg < > martijnverburg at gmail.com>, jdk8u-dev > *Subject: *Re: Marlin renderer patches for jdk8u integration > > > > Hi Paul > > > > Le lun. 4 nov. 2019 ? 20:30, Hohensee, Paul a > ?crit : > > Also, we (Amazon) would like the Marlin renderer enabled by default, just > as it is for Zulu. It's been well-tested starting in 9, plus I doubt it'll > get much, if any, use in u242 if we e.g. disable it for u242 and then > enable it for u252. > > Please put the patches on cr.openjdk.java.net so we can go through a > normal review process. > > > > I uploaded all patch files (m01 to m21): > > http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/ > > > > Laurent > From neugens at redhat.com Mon Feb 10 14:30:37 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 10 Feb 2020 15:30:37 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u Message-ID: Hi all, During the OpenJDK Committers Workshop it was requested to enable JFR by default, and the proposed patch does exactly that. http://cr.openjdk.java.net/~neugens/8238590/webrev.00/jdk8u-jfr-incubator.changeset Can somebody please review it? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Mon Feb 10 16:25:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 10 Feb 2020 17:25:08 +0100 Subject: Pull Jan 2020 CPU: jdk8u/jdk8u -> jdk8u/jdk8u-dev In-Reply-To: References: <9fe44186-494b-f2e5-3fa2-e7b41d06b26d@redhat.com> Message-ID: On 1/28/20 6:58 AM, Andrew John Hughes wrote: > On 27/01/2020 10:50, Aleksey Shipilev wrote: >> Please pull jdk8u/jdk8u -> jdk8u/jdk8u-dev, which should bring the recent CPU fixes. >> >> Specifically, I am looking for this change to be in 8u-dev: >> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5ef236679ae9 >> >> ...because there is a follow-up bug reported related to it, and it requires further 8u backport: >> https://bugs.openjdk.java.net/browse/JDK-8237368 > > Yes, I deliberately haven't done so yet, because JDK-8193255 and > associated bugs need to be in 8u-dev first, to avoid conflicts with the > shortcut backports of certificate updates we allowed late in the 8u242 > cycle. > > I have a backport pretty much done, which I'll post tomorrow. That still did not happen? Because I still do not see this in jdk8u-dev: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/5ef236679ae9 https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/log?rev=8230967%3A+Improve+Registry+support+of+clients -- Thanks, -Aleksey From andrew_m_leonard at uk.ibm.com Tue Feb 11 14:34:58 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 11 Feb 2020 14:34:58 +0000 Subject: jdk8u252-b02 missing jdk8u242-b08 fixes..? Message-ID: Hi, I've probably missed something here, but it seems the recently tagged jdk8u252-b01/b02 ea builds are not based off of or include the jdk8u242-b08(ga). Is it intentional that 252 is not including 242 ga fixes? jdk8u252 branch is merged into jdk8u "tip", but the jdk8u252 "tags" are on the source branch? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Tue Feb 11 14:52:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 11 Feb 2020 15:52:11 +0100 Subject: jdk8u252-b02 missing jdk8u242-b08 fixes..? In-Reply-To: References: Message-ID: Hi Andrew, On Tue, 2020-02-11 at 14:34 +0000, Andrew Leonard wrote: > Hi, > I've probably missed something here, but it seems the recently tagged > jdk8u252-b01/b02 ea builds are not based off of or include the > jdk8u242-b08(ga). Is it intentional that 252 is not including 242 ga > fixes? > jdk8u252 branch is merged into jdk8u "tip", but the jdk8u252 "tags" are on > the source branch? Yes, that's correct. jdk8u/jdk8u => jdk8u/jdk8u-dev hasn't been merged yet. It's planned. See: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011038.html Stay tuned. Thanks, Severin > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From neugens at redhat.com Wed Feb 12 11:42:57 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 12 Feb 2020 12:42:57 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u Message-ID: Hi all, Following the initial review discussion, here is a patch to cleanup some of the issues that surfaced in the review thread. The patches are meant to apply on top of the jfr-incubator/hotspot and jdk repositories: hotspot: http://cr.openjdk.java.net/~neugens/8238589/webrev.00/ jdk: http://cr.openjdk.java.net/~neugens/8238589-jdk/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8238589 Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Wed Feb 12 11:49:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 12:49:24 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: Message-ID: On 2/12/20 12:42 PM, Mario Torre wrote: > hotspot: > http://cr.openjdk.java.net/~neugens/8238589/webrev.00/ *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling the branch when jfr_event_handler_proxy is accidentally uninitialized: 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); *) In biasedLocking.cpp, no wait, this disables revoke_bias call at L505, why? 503 #if INCLUDE_JFR 504 JavaThread* biased_locker = NULL; 505 _status_code = revoke_bias((*_obj)(), false, false, _requesting_thread, &biased_locker); 506 if (biased_locker != NULL) { 507 _biased_locker_id = JFR_THREAD_ID(biased_locker); 508 } 509 #endif // INCLUDE_JFR 510 > jdk: > http://cr.openjdk.java.net/~neugens/8238589-jdk/webrev.00/ Looks fine. -- Thanks, -Aleksey From neugens at redhat.com Wed Feb 12 11:49:31 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 12 Feb 2020 12:49:31 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing Message-ID: Hi all, There are some jtreg failures with the current state of the jfr incubator repository, this patch fixes them: hotspot: http://cr.openjdk.java.net/~neugens/8230707/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8230707 Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Wed Feb 12 11:53:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 12:53:21 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: <3c17ad83-e46c-7dc8-9f2a-f9d7eab3f20f@redhat.com> On 2/12/20 12:49 PM, Mario Torre wrote: > hotspot: > http://cr.openjdk.java.net/~neugens/8230707/webrev.00/ Looks fine. -- Thanks, -Aleksey From neugens at redhat.com Wed Feb 12 12:42:18 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 12 Feb 2020 13:42:18 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: Message-ID: On Wed, Feb 12, 2020 at 12:49 PM Aleksey Shipilev wrote:> > On 2/12/20 12:42 PM, Mario Torre wrote: > > hotspot: > > http://cr.openjdk.java.net/~neugens/8238589/webrev.00/ > > *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling > the branch when jfr_event_handler_proxy is accidentally uninitialized: > > 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); But if jfr_event_handler_proxy is null then also class_name needs to be null for the code to be executed, I don't think this is possible? > *) In biasedLocking.cpp, no wait, this disables revoke_bias call at L505, why? > > 503 #if INCLUDE_JFR > 504 JavaThread* biased_locker = NULL; > 505 _status_code = revoke_bias((*_obj)(), false, false, _requesting_thread, &biased_locker); > 506 if (biased_locker != NULL) { > 507 _biased_locker_id = JFR_THREAD_ID(biased_locker); > 508 } > 509 #endif // INCLUDE_JFR > 510 Oh, good catch, here's the updated webrev: http://cr.openjdk.java.net/~neugens/8238589/webrev.02/ > > jdk: > > http://cr.openjdk.java.net/~neugens/8238589-jdk/webrev.00/ > > Looks fine. Thanks for the review! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Wed Feb 12 15:36:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 16:36:58 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: Message-ID: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> On 2/12/20 1:42 PM, Mario Torre wrote: >> *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling >> the branch when jfr_event_handler_proxy is accidentally uninitialized: >> >> 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); > > But if jfr_event_handler_proxy is null then also class_name needs to > be null for the code to be executed, I don't think this is possible? I don't want these two things to interact. So this is why you need the assert before the branch to verify that we are testing against the sane value: #if INCLUDE_JFR assert(jfr_event_handler_proxy != NULL, "invariant"); if (k.is_null() && (class_name == jfr_event_handler_proxy)) { ... > http://cr.openjdk.java.net/~neugens/8238589/webrev.02/ Otherwise looks fine. Stylistically, I don't think you need the comment at #endif of short blocks like: 259 #if INCLUDE_JFR 260 // If requested, return information on which thread held the bias 261 if (biased_locker != NULL) { 262 *biased_locker = biased_thread; 263 } 264 #endif // INCLUDE_JFR ...as it is dead obvious what that #endif belongs to. -- Thanks, -Aleksey From andrey at azul.com Wed Feb 12 15:56:58 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 12 Feb 2020 15:56:58 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> Message-ID: <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> Hi guys, On 12.02.2020 18:36, Aleksey Shipilev wrote: > On 2/12/20 1:42 PM, Mario Torre wrote: >>> *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling >>> the branch when jfr_event_handler_proxy is accidentally uninitialized: >>> >>> 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); >> But if jfr_event_handler_proxy is null then also class_name needs to >> be null for the code to be executed, I don't think this is possible? > I don't want these two things to interact. So this is why you need the assert before the branch to > verify that we are testing against the sane value: > > #if INCLUDE_JFR > assert(jfr_event_handler_proxy != NULL, "invariant"); > if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > ... Just please be aware that it's legit to have jfr_event_handler_proxy == NULL for a while during VM startup, including while loading a few bootstrap classes. So if you put this assert unconditionally you'll crash with it unconditionally :) (see systemDictionary.cpp lines 1910 and 1912) Andrey > >> http://cr.openjdk.java.net/~neugens/8238589/webrev.02/ > Otherwise looks fine. > > Stylistically, I don't think you need the comment at #endif of short blocks like: > > 259 #if INCLUDE_JFR > 260 // If requested, return information on which thread held the bias > 261 if (biased_locker != NULL) { > 262 *biased_locker = biased_thread; > 263 } > 264 #endif // INCLUDE_JFR > > ...as it is dead obvious what that #endif belongs to. > From neugens at redhat.com Wed Feb 12 15:59:33 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 12 Feb 2020 16:59:33 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> Message-ID: On Wed, Feb 12, 2020 at 4:37 PM Aleksey Shipilev wrote: > > On 2/12/20 1:42 PM, Mario Torre wrote: > >> *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling > >> the branch when jfr_event_handler_proxy is accidentally uninitialized: > >> > >> 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); > > > > But if jfr_event_handler_proxy is null then also class_name needs to > > be null for the code to be executed, I don't think this is possible? > > I don't want these two things to interact. So this is why you need the assert before the branch to > verify that we are testing against the sane value: > > #if INCLUDE_JFR > assert(jfr_event_handler_proxy != NULL, "invariant"); > if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > ... I'm a bit afraid that now the assert will be executed no matter what. Before it would fall inside an "else" so only execute if k.is_null. Am I seeing this wrong? Cheers, Mario > > http://cr.openjdk.java.net/~neugens/8238589/webrev.02/ > > Otherwise looks fine. > > Stylistically, I don't think you need the comment at #endif of short blocks like: > > 259 #if INCLUDE_JFR > 260 // If requested, return information on which thread held the bias > 261 if (biased_locker != NULL) { > 262 *biased_locker = biased_thread; > 263 } > 264 #endif // INCLUDE_JFR > > ...as it is dead obvious what that #endif belongs to. > > -- > Thanks, > -Aleksey > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Wed Feb 12 16:01:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 17:01:22 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> Message-ID: On 2/12/20 4:56 PM, Andrey Petushkov wrote: >> I don't want these two things to interact. So this is why you need the assert before the branch to >> verify that we are testing against the sane value: >> >> #if INCLUDE_JFR >> assert(jfr_event_handler_proxy != NULL, "invariant"); >> if (k.is_null() && (class_name == jfr_event_handler_proxy)) { >> ... > Just please be aware that it's legit to have jfr_event_handler_proxy == > NULL for a while during VM startup, including > while loading a few bootstrap classes. So if you put this assert > unconditionally you'll crash with it unconditionally :) > (see systemDictionary.cpp lines 1910 and 1912) Oh wow, okay. Nevermind then! -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Feb 12 16:08:47 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 16:08:47 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> Message-ID: On 10/02/2020 08:48, Laurent Bourg?s wrote: > Hi David & Paul, > > Could you help me in preparing & reviewing patches (20 remain to be > integrated in 8u) to be faster ? > > Most of them apply cleanly so it consists in adding jdk8u-fix-request, wait > for yes then push in 8u-dev. > > 2nd pending request: > https://bugs.openjdk.java.net/browse/JDK-8145055 > > Only few large patches will need a RFR for 8u. > > Cheers, > Laurent > Give me a list of the bug IDs and I'll look into them. I can push after approval. I'm already aware that's necessary. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From andrey at azul.com Wed Feb 12 17:05:07 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 12 Feb 2020 17:05:07 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> Message-ID: <0aa0766b-21fe-da8b-e018-eee5bb657c43@azul.com> Hi Mario, On 12.02.2020 18:59, Mario Torre wrote: > On Wed, Feb 12, 2020 at 4:37 PM Aleksey Shipilev wrote: >> On 2/12/20 1:42 PM, Mario Torre wrote: >>>> *) In systemDictionary.cpp, this assert seems legit, no need to remove it? It guards from calling >>>> the branch when jfr_event_handler_proxy is accidentally uninitialized: >>>> >>>> 1342 assert(jfr_event_handler_proxy != NULL, "invariant"); >>> But if jfr_event_handler_proxy is null then also class_name needs to >>> be null for the code to be executed, I don't think this is possible? >> I don't want these two things to interact. So this is why you need the assert before the branch to >> verify that we are testing against the sane value: >> >> #if INCLUDE_JFR >> assert(jfr_event_handler_proxy != NULL, "invariant"); >> if (k.is_null() && (class_name == jfr_event_handler_proxy)) { >> ... > I'm a bit afraid that now the assert will be executed no matter what. > Before it would fall inside an "else" so only execute if k.is_null. > > Am I seeing this wrong? No, you're correct. It should be under k.is_null, otherwise additional measures are needed to protect from not executing it during VM init Andrey > > Cheers, > Mario > >>> http://cr.openjdk.java.net/~neugens/8238589/webrev.02/ >> Otherwise looks fine. >> >> Stylistically, I don't think you need the comment at #endif of short blocks like: >> >> 259 #if INCLUDE_JFR >> 260 // If requested, return information on which thread held the bias >> 261 if (biased_locker != NULL) { >> 262 *biased_locker = biased_thread; >> 263 } >> 264 #endif // INCLUDE_JFR >> >> ...as it is dead obvious what that #endif belongs to. >> >> -- >> Thanks, >> -Aleksey >> > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From bourges.laurent at gmail.com Wed Feb 12 17:09:43 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 12 Feb 2020 18:09:43 +0100 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> Message-ID: Hi Andrew, > On 10/02/2020 08:48, Laurent Bourg?s wrote: > > Hi David & Paul, > > > > Could you help me in preparing & reviewing patches (20 remain to be > > integrated in 8u) to be faster ? > > > > Most of them apply cleanly so it consists in adding jdk8u-fix-request, > wait > > for yes then push in 8u-dev. > > > > 2nd pending request: > > https://bugs.openjdk.java.net/browse/JDK-8145055 > > > > Only few large patches will need a RFR for 8u. > > > > Cheers, > > Laurent > > > > Give me a list of the bug IDs and I'll look into them. > > I can push after approval. I'm already aware that's necessary. > > Thanks, > -- > Andrew :) Here is the beginning of my review, giving bug ids, my comment for patches m02 (fix-8u-request submitted) to m12. All these bug patches are mostly the same, only few difference in chunks or imports (trivial). I can start a new RFR (webrev) thread for every modified patch (as explained in the workflow). I uploaded all patch files (unshuffled for 8u and proposed): http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03_to_12/ ---------------------------- 2. m02.8145055.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 3. m03.8144630.patch Review: ---------------------------- Output: OK Status: Approved Comments: RendererStats.java: import sun.awt.util.ThreadGroupUtils; => import sun.misc.ThreadGroupUtils; Identation issues in diff => same ---------------------------- 4. m04.8144446.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 5. m05.8144445.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 6. m06.8144526.patch Review: ---------------------------- Status: Approved Comments: MarlinUtils.java: import jdk.internal.misc.JavaLangAccess; => import sun.misc.JavaLangAccess; import jdk.internal.misc.SharedSecrets; => import sun.misc.SharedSecrets; ---------------------------- 7. m07.8144654.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 8. m08.8144718.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 9. m09.8149338.patch Review: Status: Approved ---------------------------- Identation issues in diff => same ---------------------------- 10. m10.8148886.patch Review: ---------------------------- Fix 2 conflicts with (skipped patch 8147443: Use the Common Cleaner in Marlin OffHeapArray) RendererContext.java: Remove lines{ // Smallest object used as Cleaner's parent reference final Object cleanerObj = new Object(); } Version.java: marlin-0.7.3-Unsafe-OpenJDK => marlin-0.7.2 ---------------------------- 11. m11.8144938.patch Review: ---------------------------- CrashNaNTest.java : diff looks different but raw/new files are the same + patched output files are the same. OK ---------------------------- 12. m12.8159093.patch Review: ---------------------------- OffHeapArray: diff are different on before / after sections (no Cleaner + reference processing) RendererContext.java: fix chunks (lines) only OK --- Cheers, Laurent From adinn at redhat.com Wed Feb 12 17:14:19 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Feb 2020 17:14:19 +0000 Subject: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler In-Reply-To: <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, On 04/02/2020 03:59, Denghui Dong wrote: > ? I'm so sorry for the late reply. > ? You are right, backport is a simpler way, so I make a webrev for the > backport of?JDK-8183925 for jdk8u-jfr-incubator.(Not sure should I > create a new thread for this backport) > ? The webrev has some?obvious?differences with the original changeset > because some codes had been introduced in JDK-8223147. > ? Please help review it. > > Webrev:?http://cr.openjdk.java.net/~ddong/8183925/ > Jira:?https://bugs.openjdk.java.net/browse/JDK-8183925 > Original > changeset:?http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/786437c6344b This is all rather messy in that the patch seems to be starting from the point where the jfr-incubator repo already contains both the old (WatcherThreadCrashProtection) and most of the new (ThreadCrashProtection) code i.e. this 'backport' is essentially just removing the old code. I'm still not clear how or why the new code was already present but it looks like the differences between this patch and the upstream one only exist because someone has already done a rather clumsy job of importing the new functionality. Anyway, whatever the reason we are here, it looks to me as if this patch means that the code will now rely on a correct copy of the upstream ThreadCrashProtection and that all the redundant code for WatcherThreadCrashProtection has been removed. So, from that point of view the patch looks ok. However, before we rush to commit this I'll note I don't see any mention of testing. Can you explain what you have done to verify that this code works as expected? regards, Andrew Dinn ----------- From gnu.andrew at redhat.com Wed Feb 12 18:17:47 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 18:17:47 +0000 Subject: jdk8u252-b02 missing jdk8u242-b08 fixes..? In-Reply-To: References: Message-ID: On 11/02/2020 14:34, Andrew Leonard wrote: > Hi, > I've probably missed something here, but it seems the recently tagged > jdk8u252-b01/b02 ea builds are not based off of or include the > jdk8u242-b08(ga). Is it intentional that 252 is not including 242 ga > fixes? > jdk8u252 branch is merged into jdk8u "tip", but the jdk8u252 "tags" are on > the source branch? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Yes, we need to resolve an issue in 8u252 first, before merging with 8u242. The issue was resolved in 8u242, but in a different way to reduce risk for the imminent release. Hence, we're keeping the two separate until the fix in 8u252 is available to obsolete that in 8u242. Hope that makes sense, and apologies for the confusion. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Feb 12 18:23:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 19:23:00 +0100 Subject: RFR: [8u] 8229767: Typo in java.security: Sasl.createClient and Sasl.createServer In-Reply-To: References: Message-ID: <53f56839-6adf-bdb6-6a61-6b68c4881286@redhat.com> On 2/6/20 4:08 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229767 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8229767/webrev.01/ Backport looks good. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Feb 12 18:24:26 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 18:24:26 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: On 12/02/2020 11:49, Mario Torre wrote: > Hi all, > > There are some jtreg failures with the current state of the jfr > incubator repository, this patch fixes them: > > hotspot: > http://cr.openjdk.java.net/~neugens/8230707/webrev.00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8230707 > > Cheers, > Mario > I see this is an 8u-JFR specific bug. Are these issues unique to the 8u version and not resolved by existing bugs in 11u+? Creating new bugs for 8u should be fairly rare, not the norm. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Feb 12 18:47:29 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 18:47:29 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> Message-ID: <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> On 12/02/2020 17:09, Laurent Bourg?s wrote: snip... > > Here is the beginning of my review, giving bug ids, my comment for > patches m02 (fix-8u-request submitted) to m12. > All these bug patches are mostly the same, only few difference in chunks > or imports (trivial). > > I can start a new RFR (webrev) thread for every modified patch (as > explained in the workflow). > > I uploaded all patch files (unshuffled for 8u and proposed): > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03_to_12/ > I'm a little confused. When you write "Approved" below, do you mean that the bug has jdk8u-fix-yes and is ready for push? I don't see them in the approved-and-waiting queue, your previous e-mail suggested they needed approval and some still need review. > ---------------------------- > > 2. m02.8145055.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > Comments: > > Same patch > Fine to skip review and go straight to jdk8u-fix-request. > ---------------------------- > > 3. m03.8144630.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > > Comments: > > RendererStats.java: > > import sun.awt.util.ThreadGroupUtils; => import sun.misc.ThreadGroupUtils; > > > Identation issues in diff => same > Needs a quick RFR. > > ---------------------------- > > 4. m04.8144446.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > > Comments: > > Same patch > Fine to skip review and go straight to jdk8u-fix-request. > > ---------------------------- > > 5. m05.8144445.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > > Comments: > > Same patch > Fine to skip review and go straight to jdk8u-fix-request. > > ---------------------------- > > 6. m06.8144526.patch Review: > > ---------------------------- > > Status: Approved > > > Comments: > > MarlinUtils.java: > > import jdk.internal.misc.JavaLangAccess; => import sun.misc.JavaLangAccess; > > import jdk.internal.misc.SharedSecrets; => import sun.misc.SharedSecrets; > Will need a quick RFR. > > ---------------------------- > > 7. m07.8144654.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > > Comments: > > Same patch > Fine to skip review and go straight to jdk8u-fix-request. > > ---------------------------- > > 8. m08.8144718.patch Review: > > ---------------------------- > > Output: OK > > Status: Approved > > > Comments: > > Same patch > Fine to skip review and go straight to jdk8u-fix-request. > > ---------------------------- > > 9. m09.8149338.patch Review: > > Status: Approved > ---------------------------- > > Identation issues in diff => same > Did you have to alter the patch from a later OpenJDK version to get the one for 8u? If so, it needs review. > > ---------------------------- > > 10. m10.8148886.patch Review: > > ---------------------------- > > Fix 2 conflicts with (skipped patch 8147443: Use the Common Cleaner in > Marlin OffHeapArray) > > > RendererContext.java: > > Remove lines{ > > // Smallest object used as Cleaner's parent reference > > final Object cleanerObj = new Object(); > > } > > > Version.java: > > marlin-0.7.3-Unsafe-OpenJDK => marlin-0.7.2 > Will need review. Please mention why 8147443 is being skipped. > > ---------------------------- > > 11. m11.8144938.patch Review: > > ---------------------------- > > CrashNaNTest.java : diff looks different but raw/new files are the same > + patched output files are the same. > > OK > Sounds like it needs review to confirm. > > ---------------------------- > > 12. m12.8159093.patch Review: > > ---------------------------- > > OffHeapArray: > > diff are different on before / after sections (no Cleaner + reference > processing) > > > RendererContext.java: > > fix chunks (lines) only > > OK > Will need review. > --- > > Cheers, > Laurent Assuming these need to be committed in this order, we can approve & push 8145055 (I'll look into that now) and you should post the RFR for 8144630. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From bourges.laurent at gmail.com Wed Feb 12 22:06:10 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 12 Feb 2020 23:06:10 +0100 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> Message-ID: Andrew, Few quick answers below: > > I'm a little confused. When you write "Approved" below, do you mean that > the bug has jdk8u-fix-yes and is ready for push? I don't see them in the > approved-and-waiting queue, your previous e-mail suggested they needed > approval and some still need review. > Yes there is a misunderstanding: I carefully reviewed zulu8 patches against unshuffled patches I made from 9/10/11... to 8. Approved just means the patch is good for me, as the original author (with help from Jim Graham & Phil race). Only m02 has the jdk8u-fix-request as I prefer a step by step approach. Moreover I am not a webrev expert so I do not know how to perform incremental webrevs without committing patches. > > > > ---------------------------- > > > > 2. m02.8145055.patch Review: > > > > ---------------------------- > > > > Output: OK > > > > Status: Approved > > > > Comments: > > > > Same patch > > > > Fine to skip review and go straight to jdk8u-fix-request. > That's my tip: waiting for your fix-yes + push ... > > ---------------------------- > > > > 3. m03.8144630.patch Review: > > > > ---------------------------- > > > > Output: OK > > > > Status: Approved > > > > > > Comments: > > > > RendererStats.java: > > > > import sun.awt.util.ThreadGroupUtils; => import > sun.misc.ThreadGroupUtils; > > > > > > Identation issues in diff => same > > > > Needs a quick RFR. > I prepared files, RFR mail will come tomorrow. ... > Assuming these need to be committed in this order, we can approve & push > 8145055 (I'll look into that now) and you should post the RFR for 8144630. > Looks a good plan, then follow up in the bug list... Laurent From gnu.andrew at redhat.com Wed Feb 12 23:10:39 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 12 Feb 2020 23:10:39 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: On 08/02/2020 00:10, Bradford Wetmore wrote: > On 2/5/2020 9:40 PM, Andrew John Hughes wrote:> First of all, thanks > again for posting these patches and also for the >> comprehensive list of issues for both of them. They pretty much matched >> up with what I saw when reviewing the patches > > Great. > >> The ALPN one looks pretty clean. My only concern there is the use of >> "@since 8". Should this not be a reference to the maintenance release, >> as these methods were not part of 8 at GA? Same applies to the usage in >> the second patch too. > > I originally had this as "@since 8 MR 3" but during internal review it > was requested to use @since 8 instead.? This is what was presented/voted > during the MR phase. > Ah ok. I personally think the original MR 3 version would have been better, but I guess we're stuck with this then. >> With the RSA-PSS patch, it's hard to tell what's going on with the >> MSCAPI code, because they appear as new files in the patch. Why was it >> necessary to bring in JDK-8213009? I don't see an obvious reason for >> this. > > JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code > layout, and to a lesser degree to better support Windows-native PSS > calls using CNG (MS Windows Crypto Next Generation).? The SunMSCAPI > provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG > calls when CAPI couldn't support everything needed. > > The SunMSCAPI changes that followed would take significant effort to > extricate these reorganization changes when backporting later changes > (e.g. jdk/jdk).? We could have forward ported/merged the 8u41 code into > OpenJDK 8, but unfortunately I haven't been given a lot of cycles for > OpenJDK code. > Ok. Backporting 8213009 to make future backports easier is the route I would prefer anyway (and we've done similar in other cases). It's just hard to tell the motivation with everything in one patch. >> dependency of 8213010, but again, it's not obvious why that's required >> here either. Some more details on why some of the less obvious bugs are >> required would be helpful here. > > Ok, I've added details to a comment in JDK-8230978. > Thanks for this detailed list. It's very helpful. >> If the refactoring is necessary, a >> Git-style patch which shows the moves as renames (hg diff -g) would >> help, so we can see what is actually being changed in these files. > > I'm a bit confused, isn't the webrev already showing this: > > http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ > ---begin--- > > ...deleted... > > *??? src/windows/classes/sun/security/mscapi/CKey.java* /(was > src/windows/classes/sun/security/mscapi/Key.java)/ > > ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ > > ...deleted... > > *??? src/windows/classes/sun/security/mscapi/CSignature.java /(was > src/windows/classes/sun/security/mscapi/RSASignature.java)/ > > ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ > ---end--- > > Looking at the index.html and subsequent "Frame" for this file, I can > see both the rename and the old/new code side-by-side. I wasn't looking at the web pages, but just at the patch file (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) and comparing with the changesets from 11u. In the patch file, CKey.java (for example) appears as: --- /dev/null 2020-01-30 10:24:41.746000000 -0800 +++ new/src/windows/classes/sun/security/mscapi/CKey.java 2020-02-04 15:16:49.338689705 -0800 @@ -0,0 +1,155 @@ and same in https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/src/windows/classes/sun/security/mscapi/CKey.java.patch so it wasn't clear what actual changes were applied after the file was moved. It seems like webrev should be running hg diff with the --git option to get a more useful diff in these cases. In a git format patch, the same diff would appear as: rename from src/windows/classes/sun/security/mscapi/Key.java rename to src/windows/classes/sun/security/mscapi/CKey.java and then the diff would be as if the move hadn't happened, just showing the differences between the original Key.java and the final CKey.java. > >> As you say, the RSA-PSS patch brings in truncated MessageDigests which >> are part of "8051408: NIST SP 800-90A SecureRandom implementations". It >> would be good if the summary field could be used to say "Contains >> truncated MessageDigests from JDK-8051408", so that it then shows up if >> someone is considering 8051408 at a later date > > There are several comments to make which won't fit in the summary field > which is supposed to only be one short line [0]. > > Instead, I have added several items into the comment for JDK-8230978, > which is the main umbrella bug for the PSS work, and I will add: > > ??? Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and > OpenJDK 8u > > to the changeset, which currently reads: > > ---begin--- > 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) > 8175029: StackOverflowError in X509CRL and > X509Certificate.verify(PublicKey, Provider) > 8146293: Add support for RSASSA-PSS Signature algorithm > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI > 8205720: KeyFactory#getKeySpec and translateKey throws > NullPointerException with Invalid key > 8206171: Signature#getParameters for RSASSA-PSS throws ProviderException > when not initialized > 8213009: Refactoring existing SunMSCAPI classes > 8213010: Supporting keys created with certmgr.exe > 8214096: sun.security.util.SignatureUtil passes null parameter, so JCE > validation fails > 8215694: keytool cannot generate RSASSA-PSS certificates > 8221407: Windows 32bit build error in libsunmscapi/security.cpp > 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > 8223003: SunMSCAPI keys are not cleaned up > 8223063: Support CNG RSA keys > 8225745: NoSuchAlgorithmException exception for SHA256withECDSA with > RSASSA-PSS support > 8225180: SignedObject with invalid Key not throwing the > InvalidKeyException in Windows > 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as > AlgorithmId > 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION > Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and > OpenJDK 8u > Reviewed-by: valeriep, weijun, coffeys, pkoppula > ---end--- > I'd still prefer it was something like: Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) the reason for this being that this changeset will then show up if someone searches the repository for 8051408, but won't trigger the database to create a backport issue for it. > Did you want me to add you as a reviewer? > Please. >> Otherwise, looks good. >> >> Thanks, > > Thanks, > > Brad > > [0] https://openjdk.java.net/guide/producingChangeset.html > Thanks again, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Thu Feb 13 00:40:21 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Feb 2020 00:40:21 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> Message-ID: <87408F0F-E048-4D1C-8E7B-D20B0DB6B2C5@amazon.com> Rather than go through a pile of separate reviews, here?s a review for all the ones for which Andrew asked a review. I used the patches for the first 12 issues on the list at http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/. 8143849: has been pushed to 8u. 8145055: approved by Andrew. 8144630: lgtm. 8144446: approved by Andrew. 8144445: approved by Andrew. 8144526: lgtm. 8144654: approved by Andrew. 8144718: approved by Andrew. 8149338: lgtm. The patch looks clean to me. 8148886: lgtm. The cleanerObj definition is in the diff context lines, not in the actual diffs, so the patch applies cleanly to RendererContext.java, net of context. 8147443 uses the Cleaner and associated classes that replaced finalizers. They haven?t been backported to 8u. 8144938: lgtm. I don?t see any differences in the diffs. :) 8159093: lgtm. I don?t see any context differences. RenderContext.java isn?t in the patch. Paul From: Laurent Bourg?s Date: Wednesday, February 12, 2020 at 9:12 AM To: Andrew Hughes Cc: "Hohensee, Paul" , jdk8u-dev Subject: Re: Marlin renderer patches for jdk8u integration Hi Andrew, On 10/02/2020 08:48, Laurent Bourg?s wrote: > Hi David & Paul, > > Could you help me in preparing & reviewing patches (20 remain to be > integrated in 8u) to be faster ? > > Most of them apply cleanly so it consists in adding jdk8u-fix-request, wait > for yes then push in 8u-dev. > > 2nd pending request: > https://bugs.openjdk.java.net/browse/JDK-8145055 > > Only few large patches will need a RFR for 8u. > > Cheers, > Laurent > Give me a list of the bug IDs and I'll look into them. I can push after approval. I'm already aware that's necessary. Thanks, -- Andrew :) Here is the beginning of my review, giving bug ids, my comment for patches m02 (fix-8u-request submitted) to m12. All these bug patches are mostly the same, only few difference in chunks or imports (trivial). I can start a new RFR (webrev) thread for every modified patch (as explained in the workflow). I uploaded all patch files (unshuffled for 8u and proposed): http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03_to_12/ ---------------------------- 2. m02.8145055.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 3. m03.8144630.patch Review: ---------------------------- Output: OK Status: Approved Comments: RendererStats.java: import sun.awt.util.ThreadGroupUtils; => import sun.misc.ThreadGroupUtils; Identation issues in diff => same ---------------------------- 4. m04.8144446.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 5. m05.8144445.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 6. m06.8144526.patch Review: ---------------------------- Status: Approved Comments: MarlinUtils.java: import jdk.internal.misc.JavaLangAccess; => import sun.misc.JavaLangAccess; import jdk.internal.misc.SharedSecrets; => import sun.misc.SharedSecrets; ---------------------------- 7. m07.8144654.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 8. m08.8144718.patch Review: ---------------------------- Output: OK Status: Approved Comments: Same patch ---------------------------- 9. m09.8149338.patch Review: Status: Approved ---------------------------- Identation issues in diff => same ---------------------------- 10. m10.8148886.patch Review: ---------------------------- Fix 2 conflicts with (skipped patch 8147443: Use the Common Cleaner in Marlin OffHeapArray) RendererContext.java: Remove lines{ // Smallest object used as Cleaner's parent reference final Object cleanerObj = new Object(); } Version.java: marlin-0.7.3-Unsafe-OpenJDK => marlin-0.7.2 ---------------------------- 11. m11.8144938.patch Review: ---------------------------- CrashNaNTest.java : diff looks different but raw/new files are the same + patched output files are the same. OK ---------------------------- 12. m12.8159093.patch Review: ---------------------------- OffHeapArray: diff are different on before / after sections (no Cleaner + reference processing) RendererContext.java: fix chunks (lines) only OK --- Cheers, Laurent From denghui.ddh at alibaba-inc.com Thu Feb 13 06:06:19 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 13 Feb 2020 14:06:19 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiA4MjM2MTYwOiBNaXNzaW5nIFRocmVhZENyYXNoUHJvdGVj?= =?UTF-8?B?dGlvbiBmb3IgSkZSIGluIHNpZ25hbCBoYW5kbGVy?= In-Reply-To: References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com>, Message-ID: <36372dae-7d97-4f2f-a053-eb6721aae9b1.denghui.ddh@alibaba-inc.com> Hi Andrew, Thanks for the review. Because there is no test case to verify the correctness, I added some additional code snippets (not included in the patch), diff: --- a/src/share/vm/jfr/recorder/service/jfrRecorderThreadLoop.cpp Thu Jan 30 00:21:06 2020 +0000 +++ b/src/share/vm/jfr/recorder/service/jfrRecorderThreadLoop.cpp Thu Feb 13 13:56:51 2020 +0800 @@ -30,11 +30,25 @@ #include "runtime/mutexLocker.hpp" #include "runtime/thread.inline.hpp" +class CrashCallback : public os::CrashProtectionCallback { + public: + void call() { + char* c = NULL; + *c = 'c'; + } +}; + // // Entry point for "JFR Recorder Thread" message loop. // The recorder thread executes service requests collected from the message system. // void recorderthread_entry(JavaThread* thread, Thread* unused) { + { + os::ThreadCrashProtection crash_protection; + CrashCallback cb; + crash_protection.call(cb); + } + assert(thread != NULL, "invariant"); #define START (msgs & (MSGBIT(MSG_START))) #define SHUTDOWN (msgs & MSGBIT(MSG_SHUTDOWN)) If I use the JDK without this patch to run "java -XX:StartFlightRecording version", the process will be aborted, here is an error sample: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f76e32247c1, pid=51529, tid=0x00007f765ffd3700 # # JRE version: OpenJDK Runtime Environment (8.0_212) (build 1.8.0_212-b00) # Java VM: OpenJDK 64-Bit Server VM (25.212-b00 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x6887c1] CrashCallback::call()+0x1 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /ssd1/home/ddh/dev/jdk8u-jfr-incubator1/hs_err_pid51529.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Aborted And everything is fine when I use the JDK with this patch. Do you think it's ok? Thanks Denghui Dong ------------------------------------------------------------------ From:Andrew Dinn Send Time:2020?2?13?(???) 01:14 To:???(??) ; jdk8u-dev Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler Hi Denghui, On 04/02/2020 03:59, Denghui Dong wrote: > I'm so sorry for the late reply. > You are right, backport is a simpler way, so I make a webrev for the > backport of JDK-8183925 for jdk8u-jfr-incubator.(Not sure should I > create a new thread for this backport) > The webrev has some obvious differences with the original changeset > because some codes had been introduced in JDK-8223147. > Please help review it. > > Webrev: http://cr.openjdk.java.net/~ddong/8183925/ > Jira: https://bugs.openjdk.java.net/browse/JDK-8183925 > Original > changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/786437c6344b This is all rather messy in that the patch seems to be starting from the point where the jfr-incubator repo already contains both the old (WatcherThreadCrashProtection) and most of the new (ThreadCrashProtection) code i.e. this 'backport' is essentially just removing the old code. I'm still not clear how or why the new code was already present but it looks like the differences between this patch and the upstream one only exist because someone has already done a rather clumsy job of importing the new functionality. Anyway, whatever the reason we are here, it looks to me as if this patch means that the code will now rely on a correct copy of the upstream ThreadCrashProtection and that all the redundant code for WatcherThreadCrashProtection has been removed. So, from that point of view the patch looks ok. However, before we rush to commit this I'll note I don't see any mention of testing. Can you explain what you have done to verify that this code works as expected? regards, Andrew Dinn ----------- From neugens at redhat.com Thu Feb 13 06:14:04 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 13 Feb 2020 07:14:04 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: Hi Andrew, I agree, but I don?t see a way out, given the size and scope of this backport. Cheers, Mario On Wednesday, February 12, 2020, Andrew John Hughes wrote: > > > On 12/02/2020 11:49, Mario Torre wrote: > > Hi all, > > > > There are some jtreg failures with the current state of the jfr > > incubator repository, this patch fixes them: > > > > hotspot: > > http://cr.openjdk.java.net/~neugens/8230707/webrev.00/ > > > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8230707 > > > > Cheers, > > Mario > > > > I see this is an 8u-JFR specific bug. Are these issues unique to the 8u > version and not resolved by existing bugs in 11u+? > > Creating new bugs for 8u should be fairly rare, not the norm. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Thu Feb 13 07:17:17 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 07:17:17 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> Message-ID: On 12/02/2020 22:06, Laurent Bourg?s wrote: > Andrew, > > Few quick answers below: > > > I'm a little confused. When you write "Approved" below, do you mean that > the bug has jdk8u-fix-yes and is ready for push? I don't see them in the > approved-and-waiting queue, your previous e-mail suggested they needed > approval and some still need review. > > > Yes there is a misunderstanding: I carefully reviewed zulu8 patches > against unshuffled patches I made from 9/10/11... to 8. > Approved just means the patch is good for me, as the original author > (with help from Jim Graham & Phil race). > Only m02 has the jdk8u-fix-request as I prefer a step by step approach. > Me too. In that case, I'll just ignore the status line in those comments. > Moreover I am not a webrev expert so I do not know how to perform > incremental webrevs without committing patches. I believe you can use -r to specify the revision to compare against, but it is much simpler to just proceed one by one. Such webrevs wouldn't be much use for someone else to apply to their own repositories anyway. > > > > > ---------------------------- > > > > 2. m02.8145055.patch Review: > > > > ---------------------------- > > > > Output: OK > > > > Status: Approved > > > > Comments: > > > > Same patch > > > > Fine to skip review and go straight to jdk8u-fix-request. > > > That's my tip: waiting for your fix-yes + push ... Done. > > > > ---------------------------- > > > > 3. m03.8144630.patch Review: > > > > ---------------------------- > > > > Output: OK > > > > Status: Approved > > > > > > Comments: > > > > RendererStats.java: > > > > import sun.awt.util.ThreadGroupUtils; => import > sun.misc.ThreadGroupUtils; > > > > > > Identation issues in diff => same > > > > Needs a quick RFR. > > > I prepared files, RFR mail will come tomorrow. I look forward to it. > > ... > > > Assuming these need to be committed in this order, we can approve & push > 8145055 (I'll look into that now) and you should post the RFR for > 8144630. > > > Looks a good plan, then follow up in the bug list... > > Laurent Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 13 07:17:47 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 07:17:47 +0000 Subject: RFR: [8u] 8229767: Typo in java.security: Sasl.createClient and Sasl.createServer In-Reply-To: <53f56839-6adf-bdb6-6a61-6b68c4881286@redhat.com> References: <53f56839-6adf-bdb6-6a61-6b68c4881286@redhat.com> Message-ID: On 12/02/2020 18:23, Aleksey Shipilev wrote: > On 2/6/20 4:08 AM, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229767 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8229767/webrev.01/ > > Backport looks good. > Thanks, pushed. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 13 07:27:43 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 07:27:43 +0000 Subject: RFR: [8u] 8225392: Comparison builds are failing due to cacerts file Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8225392 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.01/ This is the follow-up to 8193255 and requires similar changes to GenerateCacerts.java in order for it to build during bootstrap with OpenJDK 7. Differences from 11u version: 1. In GenerateCacerts.java, we again use a loop over the directory entries using Files.newDirectoryStream rather than a bunch of lambda functions and the Streams API. Instead of creating an unsorted list and then sorting it, we just add the entries directly to a TreeSet. 2. In GenerateCacerts.java and the test VerifyCACerts.java, we again apply the change from JDK-8235142 of using Paths.get rather than Path.of, which is only available in OpenJDK 11+. 3. The ListOrder.java test case @library and import lines are altered to match the locations used in OpenJDK 8u for other tests in test/sun/security/tools/keytool Both VerifyCACerts.java & ListOrder.java fail before the patch, and pass after. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From bourges.laurent at gmail.com Thu Feb 13 08:31:35 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 13 Feb 2020 09:31:35 +0100 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: <87408F0F-E048-4D1C-8E7B-D20B0DB6B2C5@amazon.com> References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <87408F0F-E048-4D1C-8E7B-D20B0DB6B2C5@amazon.com> Message-ID: Dear Paul, Thank you for being promptly back ! Le jeu. 13 f?vr. 2020 ? 01:40, Hohensee, Paul a ?crit : > Rather than go through a pile of separate reviews, here?s a review for all > the ones for which Andrew asked a review. I used the patches for the first > 12 issues on the list at > http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/. > I suppose it is in fact: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03_to_12/ > > > 8143849: has been pushed to 8u. > > > > 8145055: approved by Andrew. > > > > 8144630: lgtm. > > > > 8144446: approved by Andrew. > > 8144445: approved by Andrew. > > > > 8144526: lgtm. > > > > 8144654: approved by Andrew. > > 8144718: approved by Andrew. > > > > 8149338: lgtm. The patch looks clean to me. > > > > 8148886: lgtm. The cleanerObj definition is in the diff context lines, not > in the actual diffs, so the patch applies cleanly to RendererContext.java, > net of context. 8147443 uses the Cleaner and associated classes that > replaced finalizers. They haven?t been backported to 8u. > > > > 8144938: lgtm. I don?t see any differences in the diffs. :) > > > > 8159093: lgtm. I don?t see any context differences. RenderContext.java > isn?t in the patch. > I will start one Official RFR thread per bug needing a review according to Andrew: 6 in total. Please approve these RFR directly to follow the backport process. Thank you in advance, Laurent From adinn at redhat.com Thu Feb 13 10:46:01 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 Feb 2020 10:46:01 +0000 Subject: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler In-Reply-To: <36372dae-7d97-4f2f-a053-eb6721aae9b1.denghui.ddh@alibaba-inc.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> <36372dae-7d97-4f2f-a053-eb6721aae9b1.denghui.ddh@alibaba-inc.com> Message-ID: <3cf6eaca-f791-70d4-fe65-7574dedd5088@redhat.com> Hi Denghui, On 13/02/2020 06:06, Denghui Dong wrote: > Thanks for the review. > Because there is no test case to verify the correctness, I added some > additional code snippets (not included in the patch),? > . . . > If I use the JDK without this patch to run > "java?-XX:StartFlightRecording?version", the process will be aborted, > . . . > And everything is fine when I use the JDK with this patch. > Do?you?think?it's?ok? Well, that at least proves that it the new crash protection code is working. It would be better if there were a repeatable test for this (in order to ensure that it stays working). However, that also applies to the upstream code and I could not find any such test upstream. I can see why it might be hard to create such a test. I guess this will have to do. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From denghui.ddh at alibaba-inc.com Thu Feb 13 10:56:51 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 13 Feb 2020 18:56:51 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiA4MjM2MTYwOiBNaXNzaW5nIFRocmVhZENyYXNoUHJvdGVj?= =?UTF-8?B?dGlvbiBmb3IgSkZSIGluIHNpZ25hbCBoYW5kbGVy?= In-Reply-To: <3cf6eaca-f791-70d4-fe65-7574dedd5088@redhat.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> <36372dae-7d97-4f2f-a053-eb6721aae9b1.denghui.ddh@alibaba-inc.com>, <3cf6eaca-f791-70d4-fe65-7574dedd5088@redhat.com> Message-ID: <3f583312-3933-43a4-bdee-44f19cdab57b.denghui.ddh@alibaba-inc.com> Yes, it's necessary to create a repeatable test for ThreadCrashProtection, I will try it later. And could I push it to jdk8u-jfr-incubator now? Thanks Denghui Dong ------------------------------------------------------------------ From:Andrew Dinn Send Time:2020?2?13?(???) 18:46 To:???(??) ; jdk8u-dev Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler Hi Denghui, On 13/02/2020 06:06, Denghui Dong wrote: > Thanks for the review. > Because there is no test case to verify the correctness, I added some > additional code snippets (not included in the patch), > . . . > If I use the JDK without this patch to run > "java -XX:StartFlightRecording version", the process will be aborted, > . . . > And everything is fine when I use the JDK with this patch. > Do you think it's ok? Well, that at least proves that it the new crash protection code is working. It would be better if there were a repeatable test for this (in order to ensure that it stays working). However, that also applies to the upstream code and I could not find any such test upstream. I can see why it might be hard to create such a test. I guess this will have to do. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu Feb 13 12:12:26 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 Feb 2020 12:12:26 +0000 Subject: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler In-Reply-To: <3f583312-3933-43a4-bdee-44f19cdab57b.denghui.ddh@alibaba-inc.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> <106ad63e-4972-4f80-ae6d-4bb8f32030d0.denghui.ddh@alibaba-inc.com> <36372dae-7d97-4f2f-a053-eb6721aae9b1.denghui.ddh@alibaba-inc.com> <3cf6eaca-f791-70d4-fe65-7574dedd5088@redhat.com> <3f583312-3933-43a4-bdee-44f19cdab57b.denghui.ddh@alibaba-inc.com> Message-ID: <9865c5d7-69b3-fe03-5829-431a7916519f@redhat.com> On 13/02/2020 10:56, Denghui Dong wrote: > > Yes,?it's?necessary?to create > a?repeatable?test?for?ThreadCrashProtection,?I?will?try?it?later. > > And could I push it to jdk8u-jfr-incubator now? Sorry, I thought that was already clear. Yes, I am happy with this patch to be pushed now. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From bourges.laurent at gmail.com Thu Feb 13 13:25:22 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 13 Feb 2020 14:25:22 +0100 Subject: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats Message-ID: Please review this 3rd patch to backport the Marlin renderer from jdk9. JBS: https://bugs.openjdk.java.net/browse/JDK-8144630 patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev/ unshuffled patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/unshuffled/8-m03.8144630.patch Changes in RendererStats: * Fixed import: -+import sun.awt.util.ThreadGroupUtils; ++import sun.misc.ThreadGroupUtils; * Fixed indentation / chunks Best regards, Laurent From neugens at redhat.com Thu Feb 13 14:09:57 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 13 Feb 2020 15:09:57 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> Message-ID: Can I push the fix, then? Cheers, Mario On Wed, Feb 12, 2020 at 5:02 PM Aleksey Shipilev wrote: > > On 2/12/20 4:56 PM, Andrey Petushkov wrote: > >> I don't want these two things to interact. So this is why you need the assert before the branch to > >> verify that we are testing against the sane value: > >> > >> #if INCLUDE_JFR > >> assert(jfr_event_handler_proxy != NULL, "invariant"); > >> if (k.is_null() && (class_name == jfr_event_handler_proxy)) { > >> ... > > Just please be aware that it's legit to have jfr_event_handler_proxy == > > NULL for a while during VM startup, including > > while loading a few bootstrap classes. So if you put this assert > > unconditionally you'll crash with it unconditionally :) > > (see systemDictionary.cpp lines 1910 and 1912) > > Oh wow, okay. Nevermind then! > > -- > Thanks, > -Aleksey > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Thu Feb 13 14:16:30 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 13 Feb 2020 15:16:30 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: P.S. I didn't really answer your question, yes those bugs are specific to the JFR branch. Cheers, Mario On Thu, Feb 13, 2020 at 7:14 AM Mario Torre wrote: > > Hi Andrew, > > I agree, but I don?t see a way out, given the size and scope of this backport. > > Cheers, > Mario > > On Wednesday, February 12, 2020, Andrew John Hughes wrote: >> >> >> >> On 12/02/2020 11:49, Mario Torre wrote: >> > Hi all, >> > >> > There are some jtreg failures with the current state of the jfr >> > incubator repository, this patch fixes them: >> > >> > hotspot: >> > http://cr.openjdk.java.net/~neugens/8230707/webrev.00/ >> > >> > bug: >> > https://bugs.openjdk.java.net/browse/JDK-8230707 >> > >> > Cheers, >> > Mario >> > >> >> I see this is an 8u-JFR specific bug. Are these issues unique to the 8u >> version and not resolved by existing bugs in 11u+? >> >> Creating new bugs for 8u should be fairly rare, not the norm. >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Thu Feb 13 16:43:22 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 16:43:22 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: On 13/02/2020 14:16, Mario Torre wrote: > P.S. I didn't really answer your question, yes those bugs are specific > to the JFR branch. > > Cheers, > Mario > Just the JFR branch of 8u or also 11u+? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 13 16:44:27 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 16:44:27 +0000 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: <743f83b3-51c0-832c-6ee8-810a8b472ed1@redhat.com> On 10/02/2020 14:30, Mario Torre wrote: > Hi all, > > During the OpenJDK Committers Workshop it was requested to enable JFR > by default, and the proposed patch does exactly that. > > http://cr.openjdk.java.net/~neugens/8238590/webrev.00/jdk8u-jfr-incubator.changeset > > Can somebody please review it? > > Cheers, > Mario > Looks fine to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Thu Feb 13 16:45:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Feb 2020 17:45:49 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> Message-ID: On 2/13/20 3:09 PM, Mario Torre wrote: > Can I push the fix, then? Yes, I believe so. -- Thanks, -Aleksey From neugens at redhat.com Thu Feb 13 16:50:10 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 13 Feb 2020 17:50:10 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: On Thu, Feb 13, 2020 at 5:43 PM Andrew John Hughes wrote: > > > > On 13/02/2020 14:16, Mario Torre wrote: > > P.S. I didn't really answer your question, yes those bugs are specific > > to the JFR branch. > > > > Cheers, > > Mario > > > > Just the JFR branch of 8u or also 11u+? Only for 8u. We only backported the bare minimum to 11 as necessary to bring things in 8 to have a properly functional JFR, but we've been more conservative with those of course. There are a few RFC for feature backport still out in 11 I think, but in general I think we shouldn't bring new events or such all the way back, only fixes (pretty much like we do with the rest of the jdk). Btw, there's another JTreg test failing that I need to fix but forgot to add to this list so I'll need to update this webrev, I'll create a new one tomorrow as this one needs some thinking. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Thu Feb 13 16:53:21 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Feb 2020 16:53:21 +0000 Subject: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats In-Reply-To: References: Message-ID: Lgtm. Thanks, Paul From: Laurent Bourg?s Date: Thursday, February 13, 2020 at 5:25 AM To: jdk8u-dev , "Hohensee, Paul" Subject: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats Please review this 3rd patch to backport the Marlin renderer from jdk9. JBS: https://bugs.openjdk.java.net/browse/JDK-8144630 patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev/ unshuffled patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/unshuffled/8-m03.8144630.patch Changes in RendererStats: * Fixed import: -+import sun.awt.util.ThreadGroupUtils; ++import sun.misc.ThreadGroupUtils; * Fixed indentation / chunks Best regards, Laurent From shade at redhat.com Thu Feb 13 16:54:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Feb 2020 17:54:12 +0100 Subject: RFR: [8u] 8225392: Comparison builds are failing due to cacerts file In-Reply-To: References: Message-ID: <496d5595-7389-3bb7-09cd-2448c6787871@redhat.com> On 2/13/20 8:27 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8225392 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.01/ > > This is the follow-up to 8193255 and requires similar changes to > GenerateCacerts.java in order for it to build during bootstrap with > OpenJDK 7. > > Differences from 11u version: > > 1. In GenerateCacerts.java, we again use a loop over the directory > entries using Files.newDirectoryStream rather than a bunch of lambda > functions and the Streams API. Instead of creating an unsorted list and > then sorting it, we just add the entries directly to a TreeSet. But since String has the natural ordering comparator, why do you need another Comparator, which calls to String's comparator anyway? 87 SortedSet entries = new TreeSet(new Comparator () { 88 @Override 89 public int compare(String s1, String s2) { return s1.compareTo(s2); } 90 }); Surely you can just do: Collection entries = new TreeSet(); Otherwise looks good. -- Thanks, -Aleksey From hohensee at amazon.com Thu Feb 13 18:09:15 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Feb 2020 18:09:15 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <87408F0F-E048-4D1C-8E7B-D20B0DB6B2C5@amazon.com> Message-ID: Hi, Laurent, I just approved the 8144630 backport. The patches in the two directories are the same, btw. Paul From: Laurent Bourg?s Date: Thursday, February 13, 2020 at 12:32 AM To: "Hohensee, Paul" Cc: Andrew Hughes , jdk8u-dev Subject: Re: Marlin renderer patches for jdk8u integration Dear Paul, Thank you for being promptly back ! Le jeu. 13 f?vr. 2020 ? 01:40, Hohensee, Paul > a ?crit : Rather than go through a pile of separate reviews, here?s a review for all the ones for which Andrew asked a review. I used the patches for the first 12 issues on the list at http://cr.openjdk.java.net/~lbourges/marlin-jdk8/marlin-jdk8.0/. I suppose it is in fact: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03_to_12/ 8143849: has been pushed to 8u. 8145055: approved by Andrew. 8144630: lgtm. 8144446: approved by Andrew. 8144445: approved by Andrew. 8144526: lgtm. 8144654: approved by Andrew. 8144718: approved by Andrew. 8149338: lgtm. The patch looks clean to me. 8148886: lgtm. The cleanerObj definition is in the diff context lines, not in the actual diffs, so the patch applies cleanly to RendererContext.java, net of context. 8147443 uses the Cleaner and associated classes that replaced finalizers. They haven?t been backported to 8u. 8144938: lgtm. I don?t see any differences in the diffs. :) 8159093: lgtm. I don?t see any context differences. RenderContext.java isn?t in the patch. I will start one Official RFR thread per bug needing a review according to Andrew: 6 in total. Please approve these RFR directly to follow the backport process. Thank you in advance, Laurent From gnu.andrew at redhat.com Thu Feb 13 20:46:16 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 20:46:16 +0000 Subject: RFR: [8u] 8225392: Comparison builds are failing due to cacerts file In-Reply-To: <496d5595-7389-3bb7-09cd-2448c6787871@redhat.com> References: <496d5595-7389-3bb7-09cd-2448c6787871@redhat.com> Message-ID: On 13/02/2020 16:54, Aleksey Shipilev wrote: > On 2/13/20 8:27 AM, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.01/ >> >> This is the follow-up to 8193255 and requires similar changes to >> GenerateCacerts.java in order for it to build during bootstrap with >> OpenJDK 7. >> >> Differences from 11u version: >> >> 1. In GenerateCacerts.java, we again use a loop over the directory >> entries using Files.newDirectoryStream rather than a bunch of lambda >> functions and the Streams API. Instead of creating an unsorted list and >> then sorting it, we just add the entries directly to a TreeSet. > > But since String has the natural ordering comparator, why do you need another Comparator, which > calls to String's comparator anyway? > > 87 SortedSet entries = new TreeSet(new Comparator () { > 88 @Override > 89 public int compare(String s1, String s2) { return s1.compareTo(s2); } > 90 }); > > Surely you can just do: > > Collection entries = new TreeSet(); > > Otherwise looks good. > I knew there must have been a simpler solution there, but I was thrown off by the use of entries.sort(String::compareTo); in the original patch (i.e. it constructs this same Comparator implicitly using the :: notation). This explains why my search for an existing String Comparator instance was fruitless. As with the previous patch, I think we're actually improving the efficiency of this slightly by using the conventional API rather than the functional one. Revised version with the no-args constructor: https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.02/ Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Thu Feb 13 22:10:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Feb 2020 23:10:02 +0100 Subject: RFR: [8u] 8225392: Comparison builds are failing due to cacerts file In-Reply-To: References: <496d5595-7389-3bb7-09cd-2448c6787871@redhat.com> Message-ID: <52d1c77a-f660-68a4-dbb3-32f19447a9b2@redhat.com> On 2/13/20 9:46 PM, Andrew John Hughes wrote: > https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.02/ Looks fine. -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Feb 13 22:23:15 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 22:23:15 +0000 Subject: RFR: [8u] 8225392: Comparison builds are failing due to cacerts file In-Reply-To: <52d1c77a-f660-68a4-dbb3-32f19447a9b2@redhat.com> References: <496d5595-7389-3bb7-09cd-2448c6787871@redhat.com> <52d1c77a-f660-68a4-dbb3-32f19447a9b2@redhat.com> Message-ID: On 13/02/2020 22:10, Aleksey Shipilev wrote: > On 2/13/20 9:46 PM, Andrew John Hughes wrote: >> https://cr.openjdk.java.net/~andrew/openjdk8/8225392/webrev.02/ > > Looks fine. > Thanks. Flagged for Severin to approve. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From bradford.wetmore at oracle.com Thu Feb 13 22:32:23 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 13 Feb 2020 14:32:23 -0800 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> Message-ID: <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> On 2/12/2020 3:10 PM, Andrew John Hughes wrote: >> I originally had this as "@since 8 MR 3" but during internal review it >> was requested to use @since 8 instead.? This is what was presented/voted >> during the MR phase. > > Ah ok. I personally think the original MR 3 version would have been > better, I personally agree with you. > but I guess we're stuck with this then. >>> JDK-8213009 was mainly a refactor of the MSCAPI code to enhance the code >> layout, and to a lesser degree to better support Windows-native PSS >> calls using CNG (MS Windows Crypto Next Generation).? The SunMSCAPI >> provider is a mix of mostly CAPI (Windows Crypto API) and a few CNG >> calls when CAPI couldn't support everything needed. >> >> The SunMSCAPI changes that followed would take significant effort to >> extricate these reorganization changes when backporting later changes >> (e.g. jdk/jdk).? We could have forward ported/merged the 8u41 code into >> OpenJDK 8, but unfortunately I haven't been given a lot of cycles for >> OpenJDK code. > > Ok. Backporting 8213009 to make future backports easier is the route I > would prefer anyway (and we've done similar in other cases). It's just > hard to tell the motivation with everything in one patch. Agreed, thanks. >>> dependency of 8213010, but again, it's not obvious why that's required >>> here either. Some more details on why some of the less obvious bugs are >>> required would be helpful here. >> >> Ok, I've added details to a comment in JDK-8230978. > > Thanks for this detailed list. It's very helpful. Sure. >>> If the refactoring is necessary, a >>> Git-style patch which shows the moves as renames (hg diff -g) would >>> help, so we can see what is actually being changed in these files. >> >> I'm a bit confused, isn't the webrev already showing this: >> >> http://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/ >> ---begin--- >> >> ...deleted... >> >> *??? src/windows/classes/sun/security/mscapi/CKey.java* /(was >> src/windows/classes/sun/security/mscapi/Key.java)/ >> >> ///138 lines changed: 54 ins; 64 del; 20 mod; 81 unchg/ >> >> ...deleted... >> >> *??? src/windows/classes/sun/security/mscapi/CSignature.java /(was >> src/windows/classes/sun/security/mscapi/RSASignature.java)/ >> >> ///676 lines changed: 507 ins; 77 del; 92 mod; 355 unchg/ >> ---end--- >> >> Looking at the index.html and subsequent "Frame" for this file, I can >> see both the rename and the old/new code side-by-side. > > I wasn't looking at the web pages, but just at the patch file > (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) > and comparing with the changesets from 11u. I'm a hardcore webrev/frames guys, so I wouldn't have thought to closely look for this. I believe I've discovered a "bug" in webrev when specifying specific revisions. I use Mercurial Queues to handle my patches. With these revisions: r1 = current tip r2 = ALPN patch applied r3 = PSS patch applied If I have applied ALPN + PSS and I use: % webrev -r r2 -o webrev to generate the PSS-only changes, I don't get the git headers. If I don't specify -r, it defaults to r1 (current tip): % webrev -o webrev Then I do see the git changes, but unfortunately both ALPN+PSS show up in a unified webrev. >> ---begin--- >> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >> ...deleted... >> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >> Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and >> OpenJDK 8u >> Reviewed-by: valeriep, weijun, coffeys, pkoppula >> ---end--- >> > > I'd still prefer it was something like: > > Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) > > the reason for this being that this changeset will then show up if > someone searches the repository for 8051408, but won't trigger the > database to create a backport issue for it. Changed. >> Did you want me to add you as a reviewer? >> > > Please. Done. Brad From bevans at newrelic.com Fri Feb 14 10:43:32 2020 From: bevans at newrelic.com (Ben Evans) Date: Fri, 14 Feb 2020 11:43:32 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: Hi Mario, Some of our teams have reported noticeable performance regressions on JDK8 + JFR even with JFR disabled at runtime. I am investigating further but don't have solid evidence that I can share yet - but I would urge everyone who wants this backport to happen (at NR we very much do) to do as much performance regression testing as possible. It would not be a good look if adding this feature caused problems for other users. Thanks, Ben On Mon, Feb 10, 2020 at 3:32 PM Mario Torre wrote: > Hi all, > > During the OpenJDK Committers Workshop it was requested to enable JFR > by default, and the proposed patch does exactly that. > > > http://cr.openjdk.java.net/~neugens/8238590/webrev.00/jdk8u-jfr-incubator.changeset > > Can somebody please review it? > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > From neugens at redhat.com Fri Feb 14 12:40:17 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 14 Feb 2020 13:40:17 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: On Fri, Feb 14, 2020 at 11:43 AM Ben Evans wrote: > > Hi Mario, > > Some of our teams have reported noticeable performance regressions on JDK8 + JFR even with JFR disabled at runtime. > > I am investigating further but don't have solid evidence that I can share yet - but I would urge everyone who wants this backport to happen (at NR we very much do) to do as much performance regression testing as possible. It would not be a good look if adding this feature caused problems for other users. > Thanks Ben, I am about to prepare a new webrew for general testing based on all the latest fix we introduced in the last couple of weeks, I appreciate this kind of feedback on the new bundle, especially if it can be substantiated by some numbers. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Feb 14 17:00:09 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 14 Feb 2020 18:00:09 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: Hi Andrew and Aleksey, Here's a new webrev, it includes an additional test fix for test related to the now missing EnableTracing option. I re-added the option but it's a no-op now: http://cr.openjdk.java.net/~neugens/8230707/webrev.01/ This was possibly an incompatible change (although fine by the spec since it's hidden behind -XX), with this additional fix if someone executes with -XX:EnableTracing won't have startup issues. Cheers, Mario Cheers, Mario On Thu, Feb 13, 2020 at 5:50 PM Mario Torre wrote: > > On Thu, Feb 13, 2020 at 5:43 PM Andrew John Hughes > wrote: > > > > > > > > On 13/02/2020 14:16, Mario Torre wrote: > > > P.S. I didn't really answer your question, yes those bugs are specific > > > to the JFR branch. > > > > > > Cheers, > > > Mario > > > > > > > Just the JFR branch of 8u or also 11u+? > > Only for 8u. > > We only backported the bare minimum to 11 as necessary to bring things > in 8 to have a properly functional JFR, but we've been more > conservative with those of course. There are a few RFC for feature > backport still out in 11 I think, but in general I think we shouldn't > bring new events or such all the way back, only fixes (pretty much > like we do with the rest of the jdk). > > Btw, there's another JTreg test failing that I need to fix but forgot > to add to this list so I'll need to update this webrev, I'll create a > new one tomorrow as this one needs some thinking. > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Fri Feb 14 17:15:42 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 14 Feb 2020 17:15:42 +0000 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: On 14/02/2020 12:40, Mario Torre wrote: > On Fri, Feb 14, 2020 at 11:43 AM Ben Evans wrote: >> >> Hi Mario, >> >> Some of our teams have reported noticeable performance regressions on JDK8 + JFR even with JFR disabled at runtime. >> >> I am investigating further but don't have solid evidence that I can share yet - but I would urge everyone who wants this backport to happen (at NR we very much do) to do as much performance regression testing as possible. It would not be a good look if adding this feature caused problems for other users. >> > > Thanks Ben, > > I am about to prepare a new webrew for general testing based on all > the latest fix we introduced in the last couple of weeks, I appreciate > this kind of feedback on the new bundle, especially if it can be > substantiated by some numbers. > > Cheers, > Mario > > If the plan is now to aim JFR for the July update, I'd suggest waiting until we fork for rampdown before preparing a new merge. Such merges date very quickly with new changes going into 8u, so it should be done as close to potential integration as possible. Note that it should be a *merge* so we keep the incubator history, not some mega-patch. I was going to comment on the original merge thread, but may as well say it here instead. Such integrations shouldn't be a review of the technical details of the changes. That should have been done on each individual change before integration into the incubator, and the reason to retain that history is to keep a clear mapping to that review process. I would expect considerations for integration to be on a higher level: 1. Do we want to integrate this change in the current cycle? 2. If integrated, what are the potential consequences? 3. Is the feature enabled by default? 4. What fallback options do we have if issues are discovered? My personal feeling is that we should get JFR into 8u early in the 8u262 cycle, which I expect to begin in early March. Only a limited audience will have been testing the incubator (I know fixing the 7 bootstrap was my first experiment with it), so we need to maximise the testing timeframe if we go ahead for 8u262. As to enabling by default, I would suggest that we delay this until the October cycle, so we have one cycle with the code present, but manually enabled, and then spend the 8u272 cycle explicitly testing the effects of default enablement. I think having it on by default is the right path, but there's no need to rush it. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens.limasoftware at gmail.com Fri Feb 14 17:39:41 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 14 Feb 2020 18:39:41 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: Il giorno ven 14 feb 2020 alle ore 18:16 Andrew John Hughes ha scritto: > As to enabling by default, I would suggest that we delay this until the > October cycle, so we have one cycle with the code present, but manually > enabled, and then spend the 8u272 cycle explicitly testing the effects > of default enablement. I think having it on by default is the right > path, but there's no need to rush it. Yes, I agree and this was my original idea, but during the Committers workshop was specifically asked to enable it by default right away. Nonetheless, I don't mind either way :) I can skip this change if so agreed. Btw, I'm not sure I understand what's the difference between a merge and a plain hg import of all those patches exported from jdk-incubator, history and everything are still preserved since they are part of the bug id anyway and are in this mailing list, no? Also, we never update the jfr-incubator exactly in order to apply the patches on top of the target version and rework if/what is necessary, I think this is a better strategy but I understand maintainers may have different preferences here; finally, I agree those patches should have been (and indeed were!!) reviewed during the last year, and they are also used in production by Azul and Alibaba, but still given the scope of the change an extra pair of eyes is welcomed, so while a full review isn't necessary, I hope to have feedback (by you, Andrew Dinn/Haley and whoever else has experience and knowledge of hotspot code), especially on the subtleties of some of this code, and even more so on the performance aspect, which is the one feedback we lack the most since, as you noted, not many have been playing with the incubator thus far. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gnu.andrew at redhat.com Fri Feb 14 18:41:46 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 14 Feb 2020 18:41:46 +0000 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. In-Reply-To: References: Message-ID: <1c8238c7-8672-a778-47d5-c3a7d721a752@redhat.com> On 02/10/2019 11:17, Severin Gehwolf wrote: > Hi, > > Could I get a review of this OpenJDK 8u test-fix, please? We are seeing > occasional test failures for LZcntTestI.java and/or LZcntTestL.java > when running OpenJDK 8u tier1 tests. Backporting this change from JDK 9 > fixes the issue. The JDK 9 patch didn't apply cleanly. Modifications > I've done are: > > * Record AddnTest{I,L}.java => AndnTest{L,I}.java as a rename. > * Manually removed AddnTest{I,L}.java tests as the removal rejected. > This was done part of the rename (hg mv -A source dest) > * Kept @library and @run definitions of AndnTest{I,L}.java as they > were, modulo test name (last argument). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134579 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ > > Testing: OpenJDK 8u tier1 tests on Linux x86_64 (release/fastdebug). > Relevant test(s) fails prior, passes after. > > Thoughts? > > Thanks, > Severin > Sounds like a bit of additional admin rather than any code change from the original. Approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Fri Feb 14 23:46:43 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 14 Feb 2020 23:46:43 +0000 Subject: [8u] RFA 8223158: Docked MacBook cannot start any Java Swing applications Message-ID: May I please have approval for https://bugs.openjdk.java.net/browse/JDK-8223158 It?s been pending since the middle of January. :) Thanks, Paul From hohensee at amazon.com Fri Feb 14 23:48:30 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 14 Feb 2020 23:48:30 +0000 Subject: RFR (S): 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <5443AFB8-08E3-4D16-8DC6-5724B7526F7C@amazon.com> References: <0288F111-88F2-41F6-A5A1-D1C44989298B@amazon.com> <03070d63-b45c-33de-7401-b999e17cead3@redhat.com> <5443AFB8-08E3-4D16-8DC6-5724B7526F7C@amazon.com> Message-ID: Ping. :) Thanks, Paul ?On 1/27/20, 1:10 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Thanks for the review, Andrew. The jdk14 patch is from 2019, so I updated the copyright dates to then. They'd already been updated in jdk14 by then. The jdk14 vtableStubs.cpp patch is @@ -213,7 +213,7 @@ VtableStub* s; { MutexLocker ml(VtableStubs_lock, Mutex::_no_safepoint_check_flag); - s = ShareVtableStubs ? lookup(is_vtable_stub, vtable_index) : NULL; + s = lookup(is_vtable_stub, vtable_index); if (s == NULL) { if (is_vtable_stub) { s = create_vtable_stub(vtable_index); whereas the backported patch is @@ -108,11 +108,11 @@ address VtableStubs::find_stub(bool is_vtable_stub, int vtable_index) { assert(vtable_index >= 0, "must be positive"); - VtableStub* s = ShareVtableStubs ? lookup(is_vtable_stub, vtable_index) : NULL; + VtableStub* s = lookup(is_vtable_stub, vtable_index); if (s == NULL) { if (is_vtable_stub) { s = create_vtable_stub(vtable_index); } else { s = create_itable_stub(vtable_index); The jdk14 patch includes locking the VtableStubs_lock, which latter isn't present in the 8u version. There's a syntax-only difference in that the local variable "s" is initialized as part of its declaration in the backported patch, but not in the jdk14 patch because of the lock. The test wasn't part of the original patch, so it's not in the backport either. Looking at test2.log (the sample bad log output), you have to run it "long enough" to produce a pattern of "higher lows" and then recognize that that's what's happening. That'd be a pain to write so that it works in a test harness. I ran the test on x64 with -XX:ReservedCodeCacheSize=16m and got 0 getUsage():init=2496K,commit=3968K,used=3964K,max=16384K,max=16777216 3133 getUsage():init=2496K,commit=9024K,used=8994K,max=16384K,max=16777216 6134 getUsage():init=2496K,commit=10496K,used=10455K,max=16384K,max=16777216 9135 getUsage():init=2496K,commit=11904K,used=11835K,max=16384K,max=16777216 12135 getUsage():init=2496K,commit=12800K,used=12764K,max=16384K,max=16777216 15136 getUsage():init=2496K,commit=13696K,used=13584K,max=16384K,max=16777216 18136 getUsage():init=2496K,commit=14336K,used=13681K,max=16384K,max=16777216 21137 getUsage():init=2496K,commit=14720K,used=14609K,max=16384K,max=16777216 24137 getUsage():init=2496K,commit=15616K,used=15500K,max=16384K,max=16777216 OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=16384Kb used=15814Kb max_used=15814Kb free=569Kb bounds [0x00007f5cc249d000, 0x00007f5cc349d000, 0x00007f5cc349d000] total_blobs=10852 nmethods=10339 adapters=430 compilation: disabled (not enough contiguous free space left) 27137 getUsage():init=2496K,commit=16384K,used=12701K,max=16384K,max=16777216 30138 getUsage():init=2496K,commit=16384K,used=13607K,max=16384K,max=16777216 33138 getUsage():init=2496K,commit=16384K,used=14470K,max=16384K,max=16777216 36138 getUsage():init=2496K,commit=16384K,used=15329K,max=16384K,max=16777216 39138 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 42139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 45139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 48139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 51139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 54140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 57140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 60140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216 63140 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216 66141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216 69141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216 72141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216 75142 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216 Code cache occupancy ends up static, which I suppose would be detectable. Going strictly by the rules, if we want a test, we'd have to produce one for tip and backport it. Paul On 1/24/20, 11:58 PM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 23/01/2020 20:40, Hohensee, Paul wrote: > Please review this backport to 8u. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8229345 > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f > Webrev: http://cr.openjdk.java.net/~phh/8229345/webrev.8u.00/ > > The backport applied somewhat cleanly. The exceptions were adding 2019 copyright dates, the removal of the unsupported-in-8u globals_aarch64/arm/s390.hpp patches, and a slight difference in the vtableStubs.cpp patch due to 8u not acquiring the VtableStubs_lock. > > Thanks, > Paul > Generally looks ok, though if we must add these copyright header changes, should it not be to 2020 now? Neither I nor diff see any change between the two vtableStubs.cpp patches. Is there really something different there? I agree it would be good to check the testcase on SPARC. Any idea why the test is not part of the backported changeset? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From orionllmain at gmail.com Mon Feb 17 05:20:22 2020 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 17 Feb 2020 12:20:22 +0700 Subject: Backport JDK-8058779 to JDK 8 (faster String.replace(CharSequence, CharSequence)) Message-ID: Hello, guys! Is there any reason to not backport JDK-8058779 to JDK 8? The JDK 9 implementation is very simple and it's fully localized in the method, so it's just a matter of a simple copy-paste. According to these benchmarks, it's ~3 times faster: https://stackoverflow.com/a/58199878/706317 There is still a huge amount of Java 8 code which would highly benefit from such backport. With best regards. Zheka Kozlov. From gnu.andrew at redhat.com Mon Feb 17 06:51:13 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 06:51:13 +0000 Subject: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats In-Reply-To: References: Message-ID: <1443241f-cfaf-86f9-f414-2a44e795241f@redhat.com> On 13/02/2020 13:25, Laurent Bourg?s wrote: > Please review this 3rd patch to backport the Marlin renderer from jdk9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8144630 > patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch > webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev/ > unshuffled patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/unshuffled/8-m03.8144630.patch > > Changes in RendererStats: > * Fixed import: > -+import sun.awt.util.ThreadGroupUtils; > ++import sun.misc.ThreadGroupUtils; > * Fixed indentation / chunks > > > Best regards, > Laurent > Why was it necessary to fix "indentation / chunks"? I tried applying the 8144630 changeset from OpenJDK 9 and it applied as is, so the only necessary change would seem to be the import. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Feb 17 07:18:51 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 07:18:51 +0000 Subject: RFR[8u252] - MR3 - ALPN & RSASSA-PSS in Java SE 8 In-Reply-To: <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> References: <3cfec569-df33-03b2-bf93-0042500e6f6b@redhat.com> <1b194dc5-24e9-2b17-9f1a-a8b5d869bc8b@oracle.com> Message-ID: <49c80d27-67c5-0977-c3f5-03a564364aac@redhat.com> On 13/02/2020 22:32, Bradford Wetmore wrote: snip... >> >> I wasn't looking at the web pages, but just at the patch file >> (https://cr.openjdk.java.net/~wetmore/MR3-codereview-8u252/PSS/webrev.01/jdk.patch) >> >> and comparing with the changesets from 11u. > > I'm a hardcore webrev/frames guys, so I wouldn't have thought to closely > look for this. > > I believe I've discovered a "bug" in webrev when specifying specific > revisions.? I use Mercurial Queues to handle my patches.? With these > revisions: > > ??? r1 = current tip > ??? r2 = ALPN patch applied > ??? r3 = PSS patch applied > > If I have applied ALPN + PSS and I use: > > ??? % webrev -r r2 -o webrev > > to generate the PSS-only changes, I don't get the git headers.? If I > don't specify -r, it defaults to r1 (current tip): > > ??? % webrev -o webrev > > Then I do see the git changes, but unfortunately both ALPN+PSS show up > in a unified webrev. > Yes, I've noticed this too when doing merges, as -r has to be used to avoid webrev bringing in everything along one branch of the merge. I'm not sure why though, as, in the script, the only difference when -r is specified seems to be the revision used. It does have its own logic for creating diffs so I can only imagine it doesn't correctly pick up the rename when -r is used. My best guess would be it doesn't pick up on renames correctly unless it can see them in hg status. >>> ---begin--- >>> 8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) >>> ...deleted... >>> 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION >>> Summary: See comment in JDK-8230978 for details in Oracle JDK 8u and >>> OpenJDK 8u >>> Reviewed-by: valeriep, weijun, coffeys, pkoppula >>> ---end--- >>> >> >> I'd still prefer it was something like: >> >> Summary: Contains elements of JDK-8051408 (see comments on JDK-8230978) >> >> the reason for this being that this changeset will then show up if >> someone searches the repository for 8051408, but won't trigger the >> database to create a backport issue for it. > > Changed. > >>> Did you want me to add you as a reviewer? >>> >> >> Please. > > Done. > > Brad > Thanks for the changes. Commits look good. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Feb 17 07:29:08 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 07:29:08 +0000 Subject: [8u] RFA 8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: References: Message-ID: <95cb63c0-aeae-bea7-f1cb-fc732dd4e58b@redhat.com> On 14/02/2020 23:46, Hohensee, Paul wrote: > May I please have approval for https://bugs.openjdk.java.net/browse/JDK-8223158 > > It?s been pending since the middle of January. :) > > Thanks, > Paul > Approved and pushed. The JFR bugs are clogging up the approval queue, so I'm going to remove the flag from those bugs and instead link them to a metabug, https://bugs.openjdk.java.net/browse/JDK-8239140 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Feb 17 08:44:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 09:44:25 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8230707: JFR related tests are failing In-Reply-To: References: Message-ID: <52f66dda-60b8-09a9-4a36-63db37a6750b@redhat.com> On 2/14/20 6:00 PM, Mario Torre wrote: > http://cr.openjdk.java.net/~neugens/8230707/webrev.01/ Still looks fine. -- Thanks, -Aleksey From gnu.andrew at redhat.com Mon Feb 17 08:44:39 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 08:44:39 +0000 Subject: RFR (S): 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: <0288F111-88F2-41F6-A5A1-D1C44989298B@amazon.com> <03070d63-b45c-33de-7401-b999e17cead3@redhat.com> <5443AFB8-08E3-4D16-8DC6-5724B7526F7C@amazon.com> Message-ID: On 14/02/2020 23:48, Hohensee, Paul wrote: > Ping. :) > > Thanks, > Paul > Ok, I'm fine with this. I was looking at the right-hand side of that line, so missed the lack of the type on the left-hand side :) Please flag for approval and we can get this in. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Feb 17 08:49:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 09:49:25 +0100 Subject: RFR (S): 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <0288F111-88F2-41F6-A5A1-D1C44989298B@amazon.com> References: <0288F111-88F2-41F6-A5A1-D1C44989298B@amazon.com> Message-ID: <38c01194-c0cb-3b12-6079-4c6768c17288@redhat.com> On 1/23/20 9:40 PM, Hohensee, Paul wrote: > Please review this backport to 8u. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8229345 > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f > Webrev: http://cr.openjdk.java.net/~phh/8229345/webrev.8u.00/ Looks good to me. -- Thanks, -Aleksey From shade at redhat.com Mon Feb 17 09:01:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 10:01:52 +0100 Subject: Backport JDK-8058779 to JDK 8 (faster String.replace(CharSequence, CharSequence)) In-Reply-To: References: Message-ID: On 2/17/20 6:20 AM, Zheka Kozlov wrote: > Is there any reason to not backport JDK-8058779 > to JDK 8? Backports usually come from a reverse question: is there the overwhelming reason *to* backport? This one seems to check the marks on cost/benefit front, given the relative simplicity of the patch and the performance impact is has. But as always, performance improvements usually take much less priority than bugfixes. We (RH) have quite a few candidates for 8u backports for performance, added this to our list as well. -- Thanks, -Aleksey From claes.redestad at oracle.com Mon Feb 17 09:36:26 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 10:36:26 +0100 Subject: Backport JDK-8058779 to JDK 8 (faster String.replace(CharSequence, CharSequence)) In-Reply-To: References: Message-ID: <3b9dfaf0-949f-bf2d-f2a8-7d18fc2fb9fc@oracle.com> Yes: 11 is the LTS which already have this fix, and jdk/jdk is where we should spend all be spending our time. Unsubscribing from this list, thanks for the reminder. /Claes On 2020-02-17 06:20, Zheka Kozlov wrote: > Is there any reason to not backport JDK-8058779 > to JDK 8? From orionllmain at gmail.com Mon Feb 17 09:48:35 2020 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 17 Feb 2020 16:48:35 +0700 Subject: Backport JDK-8058779 to JDK 8 (faster String.replace(CharSequence, CharSequence)) In-Reply-To: References: Message-ID: Thanks, Aleksey. Why I'm asking this is because I was surprised that https://bugs.openjdk.java.net/browse/JDK-8214687 was backported and https://bugs.openjdk.java.net/browse/JDK-8058779 was not. String.replace is obviously much more useful and common than Collections.nCopies.equals/hashCode. Zheka. ??, 17 ????. 2020 ?. ? 16:02, Aleksey Shipilev : > On 2/17/20 6:20 AM, Zheka Kozlov wrote: > > Is there any reason to not backport JDK-8058779 > > to JDK 8? > > Backports usually come from a reverse question: is there the overwhelming > reason *to* backport? > > This one seems to check the marks on cost/benefit front, given the > relative simplicity of the patch > and the performance impact is has. But as always, performance improvements > usually take much less > priority than bugfixes. We (RH) have quite a few candidates for 8u > backports for performance, added > this to our list as well. > > -- > Thanks, > -Aleksey > > From shade at redhat.com Mon Feb 17 11:24:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 12:24:16 +0100 Subject: Backport JDK-8058779 to JDK 8 (faster String.replace(CharSequence, CharSequence)) In-Reply-To: References: Message-ID: <582382ed-0d97-432c-0fd9-d9255375d9d4@redhat.com> On 2/17/20 10:48 AM, Zheka Kozlov wrote: > Why I'm asking this is because I was surprised > that?https://bugs.openjdk.java.net/browse/JDK-8214687?was backported Looking at my own backport requests, I think Oracle backports forced our hand here. > and?https://bugs.openjdk.java.net/browse/JDK-8058779?was not. ...but this one should be additionally judged by its own merits. This is not to say it has less of the merit, but it needs to be judged anyway. -- Thanks, -Aleksey From neugens at redhat.com Mon Feb 17 11:33:42 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 17 Feb 2020 12:33:42 +0100 Subject: [JFR] new patch bundle published Message-ID: Hi all, I just published a new set of patches to add on top of the latest jdk8u-dev: http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ This set includes all the patches currently in the incubator plus a patch to enable the JFR by default (which isn't in the incubator yet, pending discussion on the mailing list). I really appreciate if I could get some feedback (even as additional review eyes) and broader testing. One notable change, this revision contains JDK-8230707, which makes -XX:EnableTracing a no-op; the option is still recognised but it won't print anymore information on the command line (since this is obviously replaced by JFR). Testing, especially for performance regression, is needed and very, very welcomed :) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Mon Feb 17 16:45:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 Feb 2020 16:45:26 +0000 Subject: RFR (S): 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <38c01194-c0cb-3b12-6079-4c6768c17288@redhat.com> References: <0288F111-88F2-41F6-A5A1-D1C44989298B@amazon.com> <38c01194-c0cb-3b12-6079-4c6768c17288@redhat.com> Message-ID: <4A15CB90-DF25-4F0A-880F-34762E22257A@amazon.com> Thanks, Andrew and Aleksey, for your reviews. I've tagged the issue. Paul ?On 2/17/20, 12:50 AM, "Aleksey Shipilev" wrote: On 1/23/20 9:40 PM, Hohensee, Paul wrote: > Please review this backport to 8u. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8229345 > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f > Webrev: http://cr.openjdk.java.net/~phh/8229345/webrev.8u.00/ Looks good to me. -- Thanks, -Aleksey From gnu.andrew at redhat.com Mon Feb 17 18:08:22 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 18:08:22 +0000 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: Message-ID: <9f971b92-38d6-6b6e-f2ac-e303f691a243@redhat.com> On 14/02/2020 17:39, Mario Torre wrote: > Il giorno ven 14 feb 2020 alle ore 18:16 Andrew John Hughes > ha scritto: > >> As to enabling by default, I would suggest that we delay this until the >> October cycle, so we have one cycle with the code present, but manually >> enabled, and then spend the 8u272 cycle explicitly testing the effects >> of default enablement. I think having it on by default is the right >> path, but there's no need to rush it. > > Yes, I agree and this was my original idea, but during the Committers > workshop was specifically asked to enable it by default right away. > Nonetheless, I don't mind either way :) > > I can skip this change if so agreed. > I'm not suggesting to skip it. I'm suggesting it should happen after the release of 8u262, so there is a release with the code integrated, but disabled by default. I see no rush into turning it on for everyone by default. If someone wants to make the case for that, they are welcome to. > Btw, I'm not sure I understand what's the difference between a merge > and a plain hg import of all those patches exported from > jdk-incubator, history and everything are still preserved since they > are part of the bug id anyway and are in this mailing list, no? A lot of unnecessary work? I really don't understand why you'd not simply merge from the repository where this has been baking, rather than basically starting the whole process again. It seems to defeat the point of having the incubator repository altogether, and frankly, seems bizarre to me. > > Also, we never update the jfr-incubator exactly in order to apply the > patches on top of the target version and rework if/what is necessary, > I think this is a better strategy but I understand maintainers may > have different preferences here; finally, I agree those patches should > have been (and indeed were!!) reviewed during the last year, and they > are also used in production by Azul and Alibaba, but still given the > scope of the change an extra pair of eyes is welcomed, so while a full > review isn't necessary, I hope to have feedback (by you, Andrew > Dinn/Haley and whoever else has experience and knowledge of hotspot > code), especially on the subtleties of some of this code, and even > more so on the performance aspect, which is the one feedback we lack > the most since, as you noted, not many have been playing with the > incubator thus far. > i think, now the incubator is relatively stable and preparing for integration, you should look into doing regular merges with 8u-dev. That would enable you to use this time before we fork for 8u252 to test with the latest changes and will minimise the eventual merge with 8u-dev on integration. In my experience, regular, small merges are easier to work with, so I'd strongly suggest each build drop from here on in, starting with b03, which I'm currently testing. Note that, last night, I removed the jdk8u-jdk-request tags from the bugs and instead linked them to a metabug [0]. When you are ready to integrate, please flag that bug with jdk8u-fix-request rather than fifty-odd individual issues, which made our approval queue unusable for other issues. > Cheers, > Mario > [0] https://bugs.openjdk.java.net/browse/JDK-8239140 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Mon Feb 17 18:10:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 Feb 2020 18:10:11 +0000 Subject: [8u] RFA 8223158: Docked MacBook cannot start any Java Swing applications In-Reply-To: <95cb63c0-aeae-bea7-f1cb-fc732dd4e58b@redhat.com> References: <95cb63c0-aeae-bea7-f1cb-fc732dd4e58b@redhat.com> Message-ID: <76580173-5C24-43BA-9A84-FD03310EDE60@amazon.com> Thanks, Andrew. Paul ?On 2/16/20, 11:30 PM, "Andrew John Hughes" wrote: On 14/02/2020 23:46, Hohensee, Paul wrote: > May I please have approval for https://bugs.openjdk.java.net/browse/JDK-8223158 > > It?s been pending since the middle of January. :) > > Thanks, > Paul > Approved and pushed. The JFR bugs are clogging up the approval queue, so I'm going to remove the flag from those bugs and instead link them to a metabug, https://bugs.openjdk.java.net/browse/JDK-8239140 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Feb 17 18:13:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 19:13:40 +0100 Subject: [8u] RFR 8237368: Problem with NullPointerException in RMI TCPEndpoint.read Message-ID: <3d0eff28-b542-6a90-ac1a-53b4e4541c78@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8237368 https://hg.openjdk.java.net/jdk/jdk14/rev/39df849b3896 This is a regression since last CPU. Patch does not apply cleanly to 8u due to reshuffling: both the product fix and the test are in old places. 8u webrev: https://cr.openjdk.java.net/~shade/8237368/webrev.01/ Testing: jdk_rmi tests (new test fails before product fix, passes after) -- Thanks, -Aleksey From hohensee at amazon.com Mon Feb 17 18:30:36 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 Feb 2020 18:30:36 +0000 Subject: [8u] RFR 8237368: Problem with NullPointerException in RMI TCPEndpoint.read In-Reply-To: <3d0eff28-b542-6a90-ac1a-53b4e4541c78@redhat.com> References: <3d0eff28-b542-6a90-ac1a-53b4e4541c78@redhat.com> Message-ID: Lgtm. Paul ?On 2/17/20, 10:15 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: Original fix: https://bugs.openjdk.java.net/browse/JDK-8237368 https://hg.openjdk.java.net/jdk/jdk14/rev/39df849b3896 This is a regression since last CPU. Patch does not apply cleanly to 8u due to reshuffling: both the product fix and the test are in old places. 8u webrev: https://cr.openjdk.java.net/~shade/8237368/webrev.01/ Testing: jdk_rmi tests (new test fails before product fix, passes after) -- Thanks, -Aleksey From shade at redhat.com Mon Feb 17 18:51:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 19:51:54 +0100 Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS Message-ID: Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649 https://bugs.openjdk.java.net/browse/JDK-8236179 This patch touches many platforms in a trivial manner. But it also means 8u does not have half of the hunks: aarch64 (I will backport separately), arm32/s390/ppc (I will notify maintainers separately, if they don't read this list) 8u webrev: https://cr.openjdk.java.net/~shade/8236179/webrev.8u.01/ Testing: tier1 (running) -- Thanks, -Aleksey From shade at redhat.com Mon Feb 17 18:57:13 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 19:57:13 +0100 Subject: [8u] RFR 8237368: Problem with NullPointerException in RMI TCPEndpoint.read In-Reply-To: References: <3d0eff28-b542-6a90-ac1a-53b4e4541c78@redhat.com> Message-ID: <08d26b81-dc51-693e-c57f-3c9f5742d0f5@redhat.com> Thanks, added tags. On 2/17/20 7:30 PM, Hohensee, Paul wrote: > Lgtm. > > Paul > > ?On 2/17/20, 10:15 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8237368 > https://hg.openjdk.java.net/jdk/jdk14/rev/39df849b3896 > > This is a regression since last CPU. Patch does not apply cleanly to 8u due to reshuffling: both the > product fix and the test are in old places. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8237368/webrev.01/ > > Testing: jdk_rmi tests (new test fails before product fix, passes after) -- Thanks, -Aleksey From hohensee at amazon.com Mon Feb 17 19:08:23 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 Feb 2020 19:08:23 +0000 Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS In-Reply-To: References: Message-ID: <4623905E-F2CE-4585-9206-72EDBD292C68@amazon.com> Lgtm. The 8u ppc port doesn't include c1. Paul ?On 2/17/20, 10:53 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649 https://bugs.openjdk.java.net/browse/JDK-8236179 This patch touches many platforms in a trivial manner. But it also means 8u does not have half of the hunks: aarch64 (I will backport separately), arm32/s390/ppc (I will notify maintainers separately, if they don't read this list) 8u webrev: https://cr.openjdk.java.net/~shade/8236179/webrev.8u.01/ Testing: tier1 (running) -- Thanks, -Aleksey From hohensee at amazon.com Mon Feb 17 22:20:12 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 17 Feb 2020 22:20:12 +0000 Subject: =?utf-8?B?Q0ZWOiBOZXcgSkRLIDggVXBkYXRlcyBDb21taXR0ZXI6IExhdXJlbnQgQm91?= =?utf-8?B?cmfDqHM=?= Message-ID: I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project Committer. Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been a JDK project Committer since Java 9, and is a Committer on the Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is the author of the Marlin renderer [1], and has contributed over 45 patches to various OpenJDK projects [2, 3]. He is in the process of backporting Marlin to 8u. Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Paul Hohensee [0] http://openjdk.java.net/census#lbourges [1] https://github.com/bourgesl/marlin-renderer [2] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() [3] https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge() [4] http://openjdk.java.net/census#jdk8u [5] http://openjdk.java.net/projects/#committer-vote From volker.simonis at gmail.com Tue Feb 18 07:29:18 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Feb 2020 08:29:18 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_8_Updates_Committer=3A_Laurent_Bourg?= =?UTF-8?Q?=C3=A8s?= In-Reply-To: References: Message-ID: Vote: yes Hohensee, Paul schrieb am Mo., 17. Feb. 2020, 23:20: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project > Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been a > JDK project Committer since Java 9, and is a Committer on the > Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is the > author of the Marlin renderer [1], and has contributed over 45 patches to > various OpenJDK projects [2, 3]. He is in the process of backporting Marlin > to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() > > [3] > https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge() > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > > > From neugens.limasoftware at gmail.com Tue Feb 18 07:49:14 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 18 Feb 2020 08:49:14 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_8_Updates_Committer=3A_Laurent_Bourg?= =?UTF-8?Q?=C3=A8s?= In-Reply-To: References: Message-ID: Vote: yes, Cheers, Mario On Mon 17. Feb 2020 at 23:20, Hohensee, Paul wrote: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project > Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been a > JDK project Committer since Java 9, and is a Committer on the > Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is the > author of the Marlin renderer [1], and has contributed over 45 patches to > various OpenJDK projects [2, 3]. He is in the process of backporting Marlin > to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() > > [3] > https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge() > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From sgehwolf at redhat.com Tue Feb 18 08:27:54 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 18 Feb 2020 09:27:54 +0100 Subject: CFV: New JDK 8 Updates Committer: Laurent =?ISO-8859-1?Q?Bourg=E8s?= In-Reply-To: References: Message-ID: <55aaa6cd6c72a2536a375979303bf4fd044feab5.camel@redhat.com> Vote: yes. On Mon, 2020-02-17 at 22:20 +0000, Hohensee, Paul wrote: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates > Project Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has > been a JDK project Committer since Java 9, and is a Committer on the > Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is > the author of the Marlin renderer [1], and has contributed over 45 > patches to various OpenJDK projects [2, 3]. He is in the process of > backporting Marlin to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, > 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge( > ) > > [3] > https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge( > ) > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > > From shade at redhat.com Tue Feb 18 08:32:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Feb 2020 09:32:28 +0100 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_JDK_8_Updates_Committer=3a_Laurent_Bourg?= =?UTF-8?B?w6hz?= In-Reply-To: References: Message-ID: <74673bc4-ed56-7dc9-6eed-d67e06a9dfcb@redhat.com> Vote: yes On 2/17/20 11:20 PM, Hohensee, Paul wrote: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project Committer. -- Thanks, -Aleksey From shade at redhat.com Tue Feb 18 08:33:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Feb 2020 09:33:14 +0100 Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS In-Reply-To: <4623905E-F2CE-4585-9206-72EDBD292C68@amazon.com> References: <4623905E-F2CE-4585-9206-72EDBD292C68@amazon.com> Message-ID: <0d9e368b-3655-de26-447d-82ab2a489908@redhat.com> Thanks Paul, I added the tags. On 2/17/20 8:08 PM, Hohensee, Paul wrote: > Lgtm. The 8u ppc port doesn't include c1. > > Paul > > ?On 2/17/20, 10:53 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: > > Original fix: > https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649 > https://bugs.openjdk.java.net/browse/JDK-8236179 > > This patch touches many platforms in a trivial manner. But it also means 8u does not have half of > the hunks: aarch64 (I will backport separately), arm32/s390/ppc (I will notify maintainers > separately, if they don't read this list) > > 8u webrev: > https://cr.openjdk.java.net/~shade/8236179/webrev.8u.01/ > > Testing: tier1 (running) -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Feb 18 09:06:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 09:06:50 +0000 Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS In-Reply-To: <4623905E-F2CE-4585-9206-72EDBD292C68@amazon.com> References: <4623905E-F2CE-4585-9206-72EDBD292C68@amazon.com> Message-ID: On 17/02/2020 19:08, Hohensee, Paul wrote: > Lgtm. The 8u ppc port doesn't include c1. > > Paul > > ?On 2/17/20, 10:53 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: > > Original fix: > https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649 > https://bugs.openjdk.java.net/browse/JDK-8236179 > > This patch touches many platforms in a trivial manner. But it also means 8u does not have half of > the hunks: aarch64 (I will backport separately), arm32/s390/ppc (I will notify maintainers > separately, if they don't read this list) > > 8u webrev: > https://cr.openjdk.java.net/~shade/8236179/webrev.8u.01/ > > Testing: tier1 (running) > > -- > Thanks, > -Aleksey > > > More specifically, 8u's PPC port doesn't have 8144019: "PPC64 C1: Introduce Client Compiler" The arm32, AArch64 & s390x ports don't currently exist on 8u at all, so those omissios also look fine. Approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 09:20:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 09:20:51 +0000 Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> Message-ID: <470ddc7c-fc1b-2dc5-25be-97d024eef061@redhat.com> On 28/10/2019 09:20, Vladimir Kempik wrote: > Hello > Can anyone please take a look at this patch? > The difference between 11 and 8 is pretty simple: move one method from superclass to subclass to prevent it being compiled on every Unix system(it can?t be compiled on solaris). This code is only used on Linux so far. > > Thanks, Vladimir > > 21 ???. 2019 ?., ? 19:23, Hohensee, Paul > ???????(?): > > +jdk8u-dev > > Paul > > From: nio-dev > on behalf of Vladimir Kempik > > Date: Monday, October 21, 2019 at 2:47 AM > To: "nio-dev at openjdk.java.net" > > Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent > > Hello > > Please review backport of https://bugs.openjdk.java.net/browse/JDK-8229872 to 8u: > http://cr.openjdk.java.net/~vkempik/8229872/ojdk8/webrev.00/ > > Difference between 14/13/11 fix: getline is missing on solaris10, so getlinelen method was moved from UnixNativeDispatcher to LinuxNativeDispatcher. > Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2d40e6a7ce8e > > Such fix was already included into azul?s october psu for openjdk8 and passed all release cycle tests. > > Thanks, Vladimir > An addition to the comments above getlinelen in LinuxNativeDispatcher.c as to why it is located there rather than in UnixNativeDispatcher.c would be good for anyone trying to understand this difference in future (no need for a new webrev, just add before push). Approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 09:36:28 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 09:36:28 +0000 Subject: [8u] RFR 8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread In-Reply-To: References: Message-ID: <990d1190-efb6-3b53-c655-abaa33491c07@redhat.com> On 22/08/2019 12:48, Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to 8u. > > This patch is trivial, it corrects mis-categorized allocation type. > > This one-line patch does not apply cleanly, due to line shifts. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8219244 > Original code review thread: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032664.html > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8219244-8u/webrev.00/ > > Thanks, > > -Zhengyu > Is this any different from the 11u patch? If that applies cleanly, you don't need a review. There's no need to backport from the jdk/jdk version each time. In fact, I would recommend using the closest version, where the patch is already applied, to minimise differences. Anyway, approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Tue Feb 18 10:24:17 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Feb 2020 10:24:17 +0000 Subject: =?utf-8?B?UkU6IE5ldyBKREsgOCBVcGRhdGVzIENvbW1pdHRlcjogTGF1cmVudCBCb3Vy?= =?utf-8?B?Z8Oocw==?= In-Reply-To: References: Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Hohensee, Paul > Sent: Montag, 17. Februar 2020 23:20 > To: jdk8u-dev at openjdk.java.net > Subject: [DMARC FAILURE] CFV: New JDK 8 Updates Committer: Laurent > Bourg?s > > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project > Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been > a JDK project Committer since Java 9, and is a Committer on the Graphics- > Rasterizer, Metropolis, and JDK Updates projects [0]. He is the author of the > Marlin renderer [1], and has contributed over 45 patches to various OpenJDK > projects [2, 3]. He is in the process of backporting Marlin to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourg > es)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() > > [3] > https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author( > lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge( > ) > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > From gnu.andrew at redhat.com Tue Feb 18 10:29:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 10:29:00 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: On 27/09/2019 04:31, Gustavo Romero wrote: > Hi, > > Could the following backport for jdk8u be reviewed please? > > The original change was mainly written to provide a better > implementation for > CRC32 and CRC32C, but it also improved the CRC32 performance in general. > This > backport is the first change of a patchset comprised of 4 changes aimed to > backport all the latest CRC32 missing parts from JDK 11u. > > It's a PPC64-only change. > > Bug???? : https://bugs.openjdk.java.net/browse/JDK-8198894 > Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0 > Backport: > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8198894/ > Can we please stick to one change per webrev, please? It makes it confusing as to what will actually be pushed when a webrev refers to multiple bugs which are not part of the RFR. > It was necessary to backport it to: > > - Adapt the file names to OpenJDK 8u Fine, and doesn't warrant review on its own. > - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no > CRC32C > - Add Assembler::add_const_optimized() from "8077838: Recent > developments for ppc" [0] Cherry-picking this seems fine as we don't want to force POWER 8 as a requirement on 8u. > - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE, > ? accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1] It seems this fix should be backported as a pre-requisite. Was there a reason not to? It seems a fairly simple change from a naive perspective. > - Adapt signatures for the following functions and their callers, > accordingly to > ? "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], also > to ease > ? subsequent backports in this patchset: > ?? a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' > parameter > ?? b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter > I share Martin's concerns about this. If we must do this, I would prefer it was done as a separate change. It seems unrelated to the other changes in 8198894. A few minor issues: * The diff of the macroAssembler_ppc.cpp changes looks different from the 11u version, though there doesn't seem to be any actual difference. I don't know if it's possible to line this up better by checking no empty lines were missed. * macroAssembler_ppc.cpp, macroAssembler_ppc.hpp, stubGenerator_ppc.hpp, stubRoutines_ppc_64.hpp & stubRoutines_ppc_64.cpp include copyright header changes in the 11u patch which don't appear to be in the 8u version. Were these already present or simply missed? > > Thank you. > > Best regards, > Gustavo > > [0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718 > [1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7 > [2] https://bugs.openjdk.java.net/browse/JDK-8175369 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexander.scherbatiy at bell-sw.com Tue Feb 18 10:39:45 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Tue, 18 Feb 2020 13:39:45 +0300 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_JDK_8_Updates_Committer=3a_Laurent_Bourg?= =?UTF-8?B?w6hz?= In-Reply-To: References: Message-ID: <6c0eeabc-2c7f-7d6d-ebda-eb05ad66bcec@bell-sw.com> Vote: yes On 18.02.2020 01:20, Hohensee, Paul wrote: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been a JDK project Committer since Java 9, and is a Committer on the Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is the author of the Marlin renderer [1], and has contributed over 45 patches to various OpenJDK projects [2, 3]. He is in the process of backporting Marlin to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() > > [3] https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge() > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > > From gnu.andrew at redhat.com Tue Feb 18 10:40:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 10:40:08 +0000 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> Message-ID: On 26/08/2019 14:48, Simon Tooke wrote: > > On 8/2/2019 4:42 AM, Aleksey Shipilev wrote: >> On 7/31/19 7:12 PM, Simon Tooke wrote: >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u.01/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8215756 >>> Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 >> Looks okay. It seems webrev was generated in default mode that omits whitespace diffs. Try with -b. > > I've redone the webrev with -b, but it didn't make much difference.? > > Also, I updated the copyright one one of the files. > > new webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ > > > Thanks, > > -Simon > > Why are we chnaging the copyright dates from 2018 in the original patch to 2019? That would just seem to create trouble for later backports. I agree with Aleksey's comments in general about keeping as close to the original change as possible. Backports are not the place to be creative. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From neugens at redhat.com Tue Feb 18 10:44:00 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 18 Feb 2020 11:44:00 +0100 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> Message-ID: On Tue, Feb 18, 2020 at 11:40 AM Andrew Hughes wrote: > > Also, I updated the copyright one one of the files. > > > > new webrev: > > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ > > > > > > Thanks, > > > > -Simon > > > > > > Why are we chnaging the copyright dates from 2018 in the original patch > to 2019? That would just seem to create trouble for later backports. > > I agree with Aleksey's comments in general about keeping as close to the > original change as possible. Backports are not the place to be creative. I think this stems from the practice of updating the copyright year in files that are touched by changes, but I agree with you we shouldn't do it in backports unless the original patch also has the change. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Tue Feb 18 10:58:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 10:58:38 +0000 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: <71d543639ca7396711a8c04e78aa10ce5823c43f.camel@redhat.com> References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> <71d543639ca7396711a8c04e78aa10ce5823c43f.camel@redhat.com> Message-ID: On 11/10/2019 15:54, Severin Gehwolf wrote: > On Fri, 2019-10-11 at 16:47 +0200, Mario Torre wrote: >> Hi Severin, >> >> The patch looks good to me. > > Thanks for the review, Mario! > > Cheers, > Severin > >> On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf wrote: >>> Hi! >>> >>> I'd appreciate a review of this one. Thanks in advance! See below. >>> >>> On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote: >>>> On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Please review this 8u backport. The OpenJDK 11u patch does not apply >>>>> cleanly after path-reshuffeling due to a) test and code for jaxp are >>>>> split in JDK 8 b) Some rejects in comments - copyright and last >>>>> modified date. I've omitted rejected comments. I can manually add them >>>>> if that's preferred. See below. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 >>>>> webrevs: >>>>> jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ >>>>> jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/ >>>>> >>>>> Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on >>>>> Windows without the fix fails and passes with it. >>>>> >>>>> Thanks to Simon Tooke who helped testing this patch on Windows. >>>>> >>>>> Rejects: >>>>> $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej >>>>> --- XMLEntityManager.java >>>>> +++ XMLEntityManager.java >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. >>>>> + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. >>>>> */ >>>>> /* >>>>> * Licensed to the Apache Software Foundation (ASF) under one or more >>>>> @@ -89,7 +89,7 @@ >>>>> * @author K.Venugopal SUN Microsystems >>>>> * @author Neeraj Bajaj SUN Microsystems >>>>> * @author Sunitha Reddy SUN Microsystems >>>>> - * @LastModified: Oct 2017 >>>>> + * @LastModified: Nov 2018 >>>>> */ >>>>> public class XMLEntityManager implements XMLComponent, XMLEntityResolver { >>>>> >>>> >>>> Gentle reminder. >>> >>> Anyone? It's been a month :( >>> >>> FWIW, I've updated XMLEntityManager to include the copyright update >>> upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so >>> I've omitted that. Latest webrevs: >>> >>> webrevs: >>> jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ >>> jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/ >>> >>> Thanks, >>> Severin >>> >> >> > The copyright header was going to be my one comment about the JAXP patch, so good to see it fixed in the second revision. The @LastModified lines were added by "8193568: @LastModified tag in license header", an odd fix which is apparently not even viewable. Maybe someone will end up having to backport it just because it becomes such a pain :( With the JDK side, you don't really explain why it was necessary to convert the test from a TestNG one. Could you elaborate please? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 11:00:32 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 11:00:32 +0000 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_JDK_8_Updates_Committer=3a_Laurent_Bourg?= =?UTF-8?B?w6hz?= In-Reply-To: References: Message-ID: On 17/02/2020 22:20, Hohensee, Paul wrote: > I hereby nominate Laurent Bourg?s (lbourges) to be a JDK 8 Updates Project Committer. > > > > Laurent is Member of the 2D group, an OpenJFX project Reviewer, has been a JDK project Committer since Java 9, and is a Committer on the Graphics-Rasterizer, Metropolis, and JDK Updates projects [0]. He is the author of the Marlin renderer [1], and has contributed over 45 patches to various OpenJDK projects [2, 3]. He is in the process of backporting Marlin to 8u. > > > > Votes are due by 20h00 UTC (noon U.S. Pacific time) on March 3rd, 2020. > > > > Only current OpenJDK 8 Updates Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [5]. > > > > Paul Hohensee > > > > [0] http://openjdk.java.net/census#lbourges > > [1] https://github.com/bourgesl/marlin-renderer > > [2] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent%40gmail.com%22))+and+not+merge() > > [3] https://hg.openjdk.java.net/openjfx/jfx/rt/log?revcount=300&rev=(author(lbourges)+or+desc(%22bourges.laurent at gmail.com%22))+and+not+merge() > > [4] http://openjdk.java.net/census#jdk8u > > [5] http://openjdk.java.net/projects/#committer-vote > > > > > > > Vote: Yes Was going to raise this one myself, so thanks for saving me the trouble, Paul :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 11:03:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 11:03:45 +0000 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> Message-ID: <24ca6ca1-3713-525d-a6e6-11e09e5ce484@redhat.com> On 18/02/2020 10:44, Mario Torre wrote: > On Tue, Feb 18, 2020 at 11:40 AM Andrew Hughes wrote: >>> Also, I updated the copyright one one of the files. >>> >>> new webrev: >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ >>> >>> >>> Thanks, >>> >>> -Simon >>> >>> >> >> Why are we chnaging the copyright dates from 2018 in the original patch >> to 2019? That would just seem to create trouble for later backports. >> >> I agree with Aleksey's comments in general about keeping as close to the >> original change as possible. Backports are not the place to be creative. > > I think this stems from the practice of updating the copyright year in > files that are touched by changes, but I agree with you we shouldn't > do it in backports unless the original patch also has the change. > > Cheers, > Mario > Yes, I can see the reasoning, but I've also done enough backports that break just because of differing copyright headers, that I'd rather minimise the chance of that if possible :) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 11:16:31 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 11:16:31 +0000 Subject: [8u] RFR 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 In-Reply-To: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> References: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> Message-ID: On 16/12/2019 17:25, Zhengyu Gu wrote: > Hi, > > Please review this 8u backport, as Oracle backported this patch in 8u221 > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8210776 > Original webrev: http://cr.openjdk.java.net/~prr/8210776/ > Original review thread: > https://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014607.html > > > 8u webrev: > ? main: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/webrev.00/ > ? corba: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/corba/webrev.00/ > ? hotspot: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/hotspot/webrev.00/ > ? jaxp: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxp/webrev.00/ > ? jaxws: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxws/webrev.00/ > ? langtools: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/langtools/webrev.00/ > > ? nashorn: > http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/nashorn/webrev.00/ > > > Thanks, > > -Zhengyu > > I'm happy with the main body of this patch, and thanks for extending the license changes to all those THIRD_PARTY_README files. However, I am concerned about the change from test/jdk/java/awt/Window/ShapedAndTranslucentWindows/Common.java getting lost here. I don't know why it's attached to this change in the first place, but we should backport "JDK-8041915: Move 8 awt tests to OpenJDK regression tests tree" first, so we don't lose this. I'll take a look at the viability of this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 12:25:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 12:25:13 +0000 Subject: [8u] RFR: 8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE In-Reply-To: <5b6eb7c0facc02856ef72ca8d941f95ae2c4c041.camel@redhat.com> References: <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com> <5b6eb7c0facc02856ef72ca8d941f95ae2c4c041.camel@redhat.com> Message-ID: On 29/11/2019 16:42, Severin Gehwolf wrote: > On Fri, 2019-11-29 at 16:09 +0000, Hohensee, Paul wrote: >> Looks good. > > Thanks for the review, Paul! > >> Separately, how difficult would it be to backport the SA test infra? Should we consider doing it? > > I haven't looked at it in detail, but it may be something we should > consider doing. I doubt it's difficult, but it'll be a chunk of work. > > It basically amounts to looking at > test/hotspot/jtreg/serviceability/sa/ and checking what functionality > exists in 8u then porting it over. Not sure how much of the other test > support libraries would need to get backported too. > > Thanks, > Severin > >> Thanks, >> Paul >> Could we not include the tests but ProblemList them for now? I'm very wary of just dropping tests on the floor, because it means someone else needs to find and restore them under a separate bug later. You probably need to knock the 'jtreg' out of the path so it fits into the current OpenJDK 8u setup. JDK-8081037: "serviceability/sa/ tests time out on Windows" (introduces LingeredApp.java) and JDK-8190198: "SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands" seem to be the key issues here, but there are probably others. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Feb 18 12:43:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Feb 2020 12:43:20 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> On 03/12/2019 06:11, Yangfei (Felix) wrote: > Hi, > > > > Please review 8u backport of 8167409. > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8167409 > > http://hg.openjdk.java.net/jdk/jdk/rev/11b8ac93804c > > > > Original patch does not apply cleanly to 8u due to path differences and missing file. > > > > 8u webrev: > > http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.00/ > > > > This updated copyright years for files changed or added. > > Also added one shell script Test8167409.sh to run the newly added test case in the original patch. > > > > Testing: Run full jtreg test with a x86-64 release build. > > Newly add test case fail without the patch and pass with the patch. > > > > Thanks, > > Felix > Was the script based on one of the existing ones? It looks similar. Generally happy with the patch, but would omit the copyright header changes, as they are just going to create problems for future backports. Also, the /runtime should probably be dropped from the test path as other tests in 8u aren't under the runtime subdirectory. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From bevans at newrelic.com Tue Feb 18 13:11:14 2020 From: bevans at newrelic.com (Ben Evans) Date: Tue, 18 Feb 2020 14:11:14 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: <9f971b92-38d6-6b6e-f2ac-e303f691a243@redhat.com> References: <9f971b92-38d6-6b6e-f2ac-e303f691a243@redhat.com> Message-ID: On Mon, Feb 17, 2020 at 7:10 PM Andrew John Hughes wrote: > > > On 14/02/2020 17:39, Mario Torre wrote: > > Il giorno ven 14 feb 2020 alle ore 18:16 Andrew John Hughes > > ha scritto: > > > >> As to enabling by default, I would suggest that we delay this until the > >> October cycle, so we have one cycle with the code present, but manually > >> enabled, and then spend the 8u272 cycle explicitly testing the effects > >> of default enablement. I think having it on by default is the right > >> path, but there's no need to rush it. > > > > Yes, I agree and this was my original idea, but during the Committers > > workshop was specifically asked to enable it by default right away. > > Nonetheless, I don't mind either way :) > > > > I can skip this change if so agreed. > > > > I'm not suggesting to skip it. I'm suggesting it should happen after the > release of 8u262, so there is a release with the code integrated, but > disabled by default. > > I see no rush into turning it on for everyone by default. > I completely agree. I have anecdotal reports of performance regression with the JFR code compiled in, but those are against the incubator repo so it's not apples-apples. Having the JFR code in mainline, disabled by default but capable of manual enablement will greatly simplify the process of getting properly accurate feedback - and will hopefully mean broader testing from a wider range of users as well. I'm very, very keen to get JFR available for everyone using JDK 8, but in my opinion a few months delay is greatly preferable to the risk of a performance regression that could affect people's ability to upgrade to 8u262+ Thanks, Ben From zgu at redhat.com Tue Feb 18 13:38:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 18 Feb 2020 08:38:50 -0500 Subject: [8u] RFR 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 In-Reply-To: References: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> Message-ID: <12b6a84f-9274-9ca1-a8ad-577977c34600@redhat.com> > > I'm happy with the main body of this patch, and thanks for extending the > license changes to all those THIRD_PARTY_README files. > > However, I am concerned about the change from > test/jdk/java/awt/Window/ShapedAndTranslucentWindows/Common.java getting > lost here. I don't know why it's attached to this change in the first > place, but we should backport "JDK-8041915: Move 8 awt tests to OpenJDK > regression tests tree" first, so we don't lose this. I'll take a look at > the viability of this. Okay, I will take JDK-8041915 8u backport. -Zhengyu > > Thanks, > From neugens at redhat.com Tue Feb 18 13:44:43 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 18 Feb 2020 14:44:43 +0100 Subject: [JFR incubator] [RFR] JDK-8238590: Enable JFR by default during compilation in 8u In-Reply-To: References: <9f971b92-38d6-6b6e-f2ac-e303f691a243@redhat.com> Message-ID: On Tue, Feb 18, 2020 at 2:11 PM Ben Evans wrote: > I completely agree. I have anecdotal reports of performance regression with the JFR code compiled in, but those are against the incubator repo so it's not apples-apples. > > Having the JFR code in mainline, disabled by default but capable of manual enablement will greatly simplify the process of getting properly accurate feedback - and will hopefully mean broader testing from a wider range of users as well. > > I'm very, very keen to get JFR available for everyone using JDK 8, but in my opinion a few months delay is greatly preferable to the risk of a performance regression that could affect people's ability to upgrade to 8u262+ Hi Ben, I agree but we need some actual numbers on an apple-to-apple comparison to properly assess the cost, otherwise we risk sitting with the patch a few months without solving the underlying issue. Do you have something that is more than just anecdotal to share? Thanks! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From bourges.laurent at gmail.com Tue Feb 18 17:01:25 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 18 Feb 2020 18:01:25 +0100 Subject: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats In-Reply-To: <1443241f-cfaf-86f9-f414-2a44e795241f@redhat.com> References: <1443241f-cfaf-86f9-f414-2a44e795241f@redhat.com> Message-ID: Hi Andrew, I fixed the patch (in-place) to only fix import, no indentation change: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev.1/ Thanks, Laurent Le lun. 17 f?vr. 2020 ? 07:51, Andrew John Hughes a ?crit : > > > On 13/02/2020 13:25, Laurent Bourg?s wrote: > > Please review this 3rd patch to backport the Marlin renderer from jdk9. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8144630 > > patch: > > > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch > > webrev: > > > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev/ > > unshuffled patch: > > > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/unshuffled/8-m03.8144630.patch > > > > Changes in RendererStats: > > * Fixed import: > > -+import sun.awt.util.ThreadGroupUtils; > > ++import sun.misc.ThreadGroupUtils; > > * Fixed indentation / chunks > > > > > > Best regards, > > Laurent > > > > Why was it necessary to fix "indentation / chunks"? > > I tried applying the 8144630 changeset from OpenJDK 9 and it applied as > is, so the only necessary change would seem to be the import. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > -- -- Laurent Bourg?s From stooke at redhat.com Tue Feb 18 20:07:33 2020 From: stooke at redhat.com (Simon Tooke) Date: Tue, 18 Feb 2020 15:07:33 -0500 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <24ca6ca1-3713-525d-a6e6-11e09e5ce484@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> <24ca6ca1-3713-525d-a6e6-11e09e5ce484@redhat.com> Message-ID: <6c33df8f-29d6-4260-68a3-5adf44b70a36@redhat.com> On 2020-02-18 6:03 a.m., Andrew Hughes wrote: > > On 18/02/2020 10:44, Mario Torre wrote: >> On Tue, Feb 18, 2020 at 11:40 AM Andrew Hughes wrote: >>>> Also, I updated the copyright one one of the files. >>>> >>>> new webrev: >>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ >>>> >>>> >>>> Thanks, >>>> >>>> -Simon >>>> >>>> >>> Why are we chnaging the copyright dates from 2018 in the original patch >>> to 2019? That would just seem to create trouble for later backports. I will create a new webrev with the old copyright date and reply to this thread. The reason it was changed was that the original patch changed the original copyright date to 2018, and my thinking at the time was that that was "wrong"; if the date were to be changed, it should be updated.? Since them I've quickly come to agree with the view that the less changes the better in order to make backports as simple as possible. -simon >>> >>> I agree with Aleksey's comments in general about keeping as close to the >>> original change as possible. Backports are not the place to be creative. >> I think this stems from the practice of updating the copyright year in >> files that are touched by changes, but I agree with you we shouldn't >> do it in backports unless the original patch also has the change. >> >> Cheers, >> Mario >> > Yes, I can see the reasoning, but I've also done enough backports that > break just because of differing copyright headers, that I'd rather > minimise the chance of that if possible :) From neugens.limasoftware at gmail.com Tue Feb 18 20:08:30 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 18 Feb 2020 21:08:30 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8238589: Necessary code cleanup in JFR for JDK8u In-Reply-To: References: <45b60d31-a289-c63a-4e67-9e41d04d6c87@redhat.com> <86e45ce6-f3ef-82d9-b573-3d3418f13c0e@azul.com> Message-ID: Il giorno gio 13 feb 2020 alle ore 17:46 Aleksey Shipilev ha scritto: > > On 2/13/20 3:09 PM, Mario Torre wrote: > > Can I push the fix, then? > > Yes, I believe so. This is actually causing a compilation failure in Windows: -// JVMCI: OrderedPair is moved up to deal with compilation issues on Windows -//------------------------------OrderedPair--------------------------- -// Ordered pair of Node*. I should have trusted the comment... and I'm also clueless on why windows needs this to be there but well... I'll need to revert this one change. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From ebaron at redhat.com Tue Feb 18 23:34:34 2020 From: ebaron at redhat.com (Elliott Baron) Date: Tue, 18 Feb 2020 18:34:34 -0500 Subject: [8u] RFR Backport 8132130: Some docs cleanup Message-ID: Hi, I'd like to request a review to backport 8132130 to 8u. 8132130 contains several documentation fixes that allow 8177334 to apply more cleanly. Original fix: https://bugs.openjdk.java.net/browse/JDK-8132130 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/339e2b4a5241 The JDK 9 changeset did not apply cleanly. Aside from path changes, I made the following modifications to backport this fix to 8u: sun/security/jgss/krb5/Krb5NameElement: - For equals method, "@param name" already changed to "@param other" by "8048030: Expectations should be consistent". sun/security/krb5/Checksum: - Updated context for first constructor due to additional Javadoc introduced by "8229951: Better Ticket Granting Services". - Doc changes for other constructors in the original fix are no longer applicable due to further changes from 8229951. sun/security/krb5/Realm: - getRealmsList "@return" tag already corrected by "8133802: replace some tags (obsolete in html5) in security-libs docs". sun/security/krb5/internal/EncKDCRepPart: - Small spacing change due to "8215032: Support Kerberos cross-realm referrals (RFC 6806)". 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8132130/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Thanks, Elliott From hohensee at amazon.com Wed Feb 19 01:44:35 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 01:44:35 +0000 Subject: RFR (backport CSR): 8239395: Accounting currency format support Message-ID: Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 for a backport of JDK-8215181 to jdk11u. It?s identical to the original CSR. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 Thanks, Paul From felix.yang at huawei.com Wed Feb 19 02:36:17 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 19 Feb 2020 02:36:17 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function In-Reply-To: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> References: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Tuesday, February 18, 2020 8:43 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFR 8167409: Invalid value passed to critical JNI function > > > On 03/12/2019 06:11, Yangfei (Felix) wrote: > > Hi, > > > > > > Please review 8u backport of 8167409. > > > > > > Original bug: > > > > https://bugs.openjdk.java.net/browse/JDK-8167409 > > > > http://hg.openjdk.java.net/jdk/jdk/rev/11b8ac93804c > > > > > > Original patch does not apply cleanly to 8u due to path differences and > missing file. > > > > > > 8u webrev: > > > > http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.00/ > > > > > > This updated copyright years for files changed or added. > > > > Also added one shell script Test8167409.sh to run the newly added test case > in the original patch. > > > > > > Testing: Run full jtreg test with a x86-64 release build. > > > > Newly add test case fail without the patch and pass with the patch. > > > > Was the script based on one of the existing ones? It looks similar. Yes, modified from: hotspot/test/runtime/7107135/Test7107135.sh > Generally happy with the patch, but would omit the copyright header changes, > as they are just going to create problems for future backports. Do you mean the Copyright years update in these files? > Also, the /runtime should probably be dropped from the test path as other > tests in 8u aren't under the runtime subdirectory. Good suggestion. I can propose a new webrev if you want. Thanks, Felix From gnu.andrew at redhat.com Wed Feb 19 04:15:24 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2020 04:15:24 +0000 Subject: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid In-Reply-To: References: Message-ID: <9c16c81e-234c-5de8-2881-05176a46372b@redhat.com> On 20/08/2019 03:43, Yangfei (Felix) wrote: > Hi, > > > > May I got review for the backport of 8146792 to 8u master repo please? > > > > Webrev: http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047212 > > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a0c7a69277da > > > > This bug can always be reproduced by running jcstress test on our 64/128-core aarch64 server platform with 8u aarch64 fastdebug build. > > > > Error messge: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/yangfei/openjdk8u-aarch64/hotspot/src/share/vm/runtime/synchronizer.cpp:1252), pid=16581, tid=0x0000ffff23c7f200 > > # assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid > > # > > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-yangfei_2019_08_18_14_24-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops) > > # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.java.com/bugreport/crash.jsp > > # > > > > --------------- T H R E A D --------------- > > > > Current thread (0x0000ffff24123000): JavaThread "worker1" daemon [_thread_in_Java, id=16798, stack(0x0000ffff23a7f000,0x0000ffff23c80000)] > > > > Stack: [0x0000ffff23a7f000,0x0000ffff23c80000], sp=0x0000ffff23c7dac0, free space=2042k > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > V [libjvm.so+0x1117444] VMError::report_and_die()+0x144 > > V [libjvm.so+0x703ba4] report_vm_error(char const*, int, char const*, char const*)+0x7c > > V [libjvm.so+0x1032a78] ObjectSynchronizer::inflate(Thread*, oop)+0xbc8 > > V [libjvm.so+0x1036b40] ObjectSynchronizer::slow_exit(oop, BasicLock*, Thread*)+0x110 > > V [libjvm.so+0xeeb340] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*)+0x130 > > J 73% C2 org.openjdk.jcstress.tests.seqcst.sync.L1_S1__S1__S1__S2_L2__Test_jcstress.actor3()Ljava/lang/Void; (166 bytes) @ 0x0000ffff782c4318 [0x0000ffff782c2 > > f80+0x1398] > > C 0x0000ffff2e872650 > > > > As the patch changes shared code, it has to be backported to 8u master repo before it goes to 8u-aarch64 repo. > > Due to the use of 'PaddedEnd' in jdk9 or higher version, some trivial tweaks are necessary for the backport. > > As we changed to use ordered access for global `gBlockList`, risk should be low. > > Jtreg tested with 8u x86_64 fastdebug build. Also passed two round of jcstress test with 8u aarch64 fastdebug build. > > > > Thanks for your help, > > Felix > PaddedEnd is introduced by JDK-8049737, which is part of JEP-143, so I agree it makes sense to workaround this change rather than backport it. The code is essentially the same, minus the wrapping of the ObjectMonitor in PaddedEnd. Some minor issues: * Empty line lost between: + oop obj = (oop)mid->object(); and + if (obj == NULL) { * Empty line lost between: + deflated = deflate_monitor(mid, obj, &FreeHead, &FreeTail); and + if (deflated) { Both are in synchronizer.cpp and cause the diffs to not line up when compared with the original 9u changeset. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Feb 19 04:20:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2020 04:20:14 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> Message-ID: On 31/07/2019 16:23, Andrey Petushkov wrote: > Hi Aleksey, > > I'll do > > Thanks, > Andrey > >> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: >> >> On 7/16/19 7:42 PM, Fedor Burdun wrote: >>> The issue described in bugs 8031126/8030631 is still reproducible on java8. >>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? >> >> This makes sense. Is there anyone from Azul to assist you with following this checklist? >> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >> >> Thanks, >> -Aleksey > Is there a webrev for this backport? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From bourges.laurent at gmail.com Wed Feb 19 08:13:28 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 19 Feb 2020 09:13:28 +0100 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> Message-ID: Hi Andrew, As we started this effort to backport Marlin in openjdk 8u 252, I want this task to be finished as soon as possible. I know jd8u roadmap has a short window: RDP at 02.26 in 1 week. As Marlin renderer is disabled by default in 8u, it does not hurt. This backport can go on and will be ready in later 8u release. Currently m01 & m02 patches are pushed, m03 is in RFR. How can we go faster ? 1. Maybe I can start several RFR in parallel, but how can I tell webrev.ksh to make incremental web revs without committing every patch in my local mercurial repository. HG clone is very slow, so I can not do for every patch. I tried using a local branch (but jcheck complained, so I disabled it) but a branch can not be deleted in mercurial. I can use backups (remote tip) to manually revert / update... How do you usually make incremental web revs ? 2. RFR mails + JBS fix requests are great but this workflow imposes high latency... Maybe we could group them and follow a schedule: every wednesday RFR / fix requests must be ready / processed... patches ready be pushed. If possible, could we have a phone call ? Thanks, Laurent From shade at redhat.com Wed Feb 19 11:37:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 12:37:28 +0100 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8231430 https://hg.openjdk.java.net/jdk/jdk/rev/54af3178cdbd This is one nasty bug, and it affects 8u as well. Unfortunately, it does not apply cleanly due to context changes. Also, it misses the introduction of is_reference_type helper (part of much larger JDK-8230505), and the fatal needs to be wrapped in err_msg to match the old signature. 8u webrev: https://cr.openjdk.java.net/~shade/8231430/webrev.8u.01/ Testing: tier1 -- Thanks, -Aleksey From akashche at redhat.com Wed Feb 19 11:42:16 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 19 Feb 2020 11:42:16 +0000 Subject: [8u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) Message-ID: Please review the backport of JDK-8216472 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 Original review thread: https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html Original review thread (continuation): https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006777.html Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e 11u review thread: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002417.html 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/3f41514eef8a 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8216472/webrev.00/ 8u change is the same as in 11u, it doesn't apply cleanly to 8u because of different imports and minor code differences in java part. Testing: 8u change in this form was included with Red Hat 8u242-windows release and passed usual release testing. -- -Alex From shade at redhat.com Wed Feb 19 11:51:09 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 12:51:09 +0100 Subject: [8u] RFR 8191227: Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg() Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8191227 https://hg.openjdk.java.net/jdk/jdk/rev/bb957f109a1f The patch applies after reshuffling and fuzz. We ship parts of this fix in shenandoah/jdk8u: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011434.html I would appreciate reviews w.r.t. its bug tail. It seems to be followed up by JDK-8193699, which introduced numerous failures in itself. I don't think this fix individually causes those troubles. 8u webrev: http://cr.openjdk.java.net/~shade/8191227/webrev.8u.01/ Testing: tier1 -- Thanks, -Aleksey From shade at redhat.com Wed Feb 19 12:11:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 13:11:46 +0100 Subject: [8u] RFR 8187078: -XX:+VerifyOops finds numerous problems when running JPRT Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8187078 https://hg.openjdk.java.net/jdk/jdk/rev/8f594f75e054 The patch applies after reshuffles, except for barrierSetC1.cpp hunk, that is in c1_LIRGenerator.cpp in 8u. (It was moved by a huge JDK-8201543 later in 11). Testing: tier1, ad-hoc -XX:+VerifyOops tests -- Thanks, -Aleksey From shade at redhat.com Wed Feb 19 12:17:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 13:17:58 +0100 Subject: [8u] RFR: C1: possible overflow when strength reducing integer multiply by constant Message-ID: <8270f8b4-89b6-02aa-62c0-16098640baa3@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8181872 https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 Patch applies cleanly, except that aarch64 and arm is not in 8u, so those hunks are ignored. 8u webrev: https://cr.openjdk.java.net/~shade/8181872/webrev.8u.01/ Testing: tier1, affected test (it passes even without the fix, probably because my toolchain does not break it) -- Thanks, -Aleksey From shade at redhat.com Wed Feb 19 12:18:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 13:18:46 +0100 Subject: [8u] RFR 8181872: C1: possible overflow when strength reducing integer multiply by constant In-Reply-To: <8270f8b4-89b6-02aa-62c0-16098640baa3@redhat.com> References: <8270f8b4-89b6-02aa-62c0-16098640baa3@redhat.com> Message-ID: Replying with bug id in the subject, for archival reasons. On 2/19/20 1:17 PM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8181872 > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 > > Patch applies cleanly, except that aarch64 and arm is not in 8u, so those hunks are ignored. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8181872/webrev.8u.01/ > > Testing: tier1, affected test (it passes even without the fix, probably because my toolchain does > not break it) -- Thanks, -Aleksey From shade at redhat.com Wed Feb 19 12:22:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 13:22:49 +0100 Subject: [8u] RFR 8187078: -XX:+VerifyOops finds numerous problems when running JPRT In-Reply-To: References: Message-ID: On 2/19/20 1:11 PM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8187078 > https://hg.openjdk.java.net/jdk/jdk/rev/8f594f75e054 > > The patch applies after reshuffles, except for barrierSetC1.cpp hunk, that is in c1_LIRGenerator.cpp > in 8u. (It was moved by a huge JDK-8201543 later in 11). (sighs) 8u webrev: https://cr.openjdk.java.net/~shade/8187078/webrev.8u.01/ -- Thanks, -Aleksey From andrey at azul.com Wed Feb 19 13:00:03 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 19 Feb 2020 13:00:03 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> Message-ID: <9ae99166-7cb5-3d7f-235c-df671de6df8b@azul.com> Hi Andrew, Uploaded webrev at https://cr.openjdk.java.net/~fijiol/8031126/webrev.00/ Thanks, Andrey On 19.02.2020 07:20, Andrew Hughes wrote: > > On 31/07/2019 16:23, Andrey Petushkov wrote: >> Hi Aleksey, >> >> I'll do >> >> Thanks, >> Andrey >> >>> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: >>> >>> On 7/16/19 7:42 PM, Fedor Burdun wrote: >>>> The issue described in bugs 8031126/8030631 is still reproducible on java8. >>>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? >>> This makes sense. Is there anyone from Azul to assist you with following this checklist? >>> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >>> >>> Thanks, >>> -Aleksey > Is there a webrev for this backport? > > Thanks, From stooke at redhat.com Wed Feb 19 15:22:09 2020 From: stooke at redhat.com (Simon Tooke) Date: Wed, 19 Feb 2020 10:22:09 -0500 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <6c33df8f-29d6-4260-68a3-5adf44b70a36@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> <24ca6ca1-3713-525d-a6e6-11e09e5ce484@redhat.com> <6c33df8f-29d6-4260-68a3-5adf44b70a36@redhat.com> Message-ID: <0950e7af-19bf-f008-d87d-38892132f2c0@redhat.com> I have updated the webrev, preserving the original copyright date (as modified by the original patch). http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/03/jdk.03/ regards, -simon On 2020-02-18 3:07 p.m., Simon Tooke wrote: > > On 2020-02-18 6:03 a.m., Andrew Hughes wrote: >> >> On 18/02/2020 10:44, Mario Torre wrote: >>> On Tue, Feb 18, 2020 at 11:40 AM Andrew Hughes >>> wrote: >>>>> Also, I updated the copyright one one of the files. >>>>> >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Simon >>>>> >>>>> >>>> Why are we chnaging the copyright dates from 2018 in the original >>>> patch >>>> to 2019? That would just seem to create trouble for later backports. > > I will create a new webrev with the old copyright date and reply to > this thread. > > The reason it was changed was that the original patch changed the > original copyright date to 2018, and my thinking at the time was that > that was "wrong"; if the date were to be changed, it should be > updated.? Since them I've quickly come to agree with the view that the > less changes the better in order to make backports as simple as possible. > > -simon > >>>> >>>> I agree with Aleksey's comments in general about keeping as close >>>> to the >>>> original change as possible. Backports are not the place to be >>>> creative. >>> I think this stems from the practice of updating the copyright year in >>> files that are touched by changes, but I agree with you we shouldn't >>> do it in backports unless the original patch also has the change. >>> >>> Cheers, >>> Mario >>> >> Yes, I can see the reasoning, but I've also done enough backports that >> break just because of differing copyright headers, that I'd rather >> minimise the chance of that if possible :) From felix.yang at huawei.com Wed Feb 19 15:50:29 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 19 Feb 2020 15:50:29 +0000 Subject: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid In-Reply-To: <9c16c81e-234c-5de8-2881-05176a46372b@redhat.com> References: <9c16c81e-234c-5de8-2881-05176a46372b@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Wednesday, February 19, 2020 12:15 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: Request for Approval: Backport of 8047212 : > runtime/ParallelClassLoading/bootstrap/random/inner-complex > assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is > invalid > > > > On 20/08/2019 03:43, Yangfei (Felix) wrote: > > Hi, > > > > > > > > May I got review for the backport of 8146792 to 8u master repo please? > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047212 > > > > JDK9 Changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a0c7a69277da > > > > > > PaddedEnd is introduced by JDK-8049737, which is part of JEP-143, so I agree it > makes sense to workaround this change rather than backport it. > The code is essentially the same, minus the wrapping of the ObjectMonitor in > PaddedEnd. > > Some minor issues: > > * Empty line lost between: > > + oop obj = (oop)mid->object(); > > and > > + if (obj == NULL) { > > * Empty line lost between: > > + deflated = deflate_monitor(mid, obj, &FreeHead, &FreeTail); > > and > > + if (deflated) { > > Both are in synchronizer.cpp and cause the diffs to not line up when compared > with the original 9u changeset. Thanks for the careful review. I have updated accordingly. New webrev: http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.01/ Please help push it if it's OK to go. Best regards, Felix From hohensee at amazon.com Wed Feb 19 16:09:19 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 16:09:19 +0000 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: References: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> Message-ID: <8C09617D-2DA2-47F4-B8B7-A453D8991E53@amazon.com> So, not backportable? Paul ?On 2/19/20, 5:23 AM, "naoto.sato at oracle.com" wrote: Hi Joe, Paul, Yes, I was thinking the same. It is a spec change in 14. Naoto On 2/18/20 9:45 PM, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It?s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >> From hohensee at amazon.com Wed Feb 19 16:10:43 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 16:10:43 +0000 Subject: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats Message-ID: Also lgtm. Paul From: Laurent Bourg?s Date: Tuesday, February 18, 2020 at 9:04 AM To: Andrew Hughes Cc: jdk8u-dev , "Hohensee, Paul" Subject: Re: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats Hi Andrew, I fixed the patch (in-place) to only fix import, no indentation change: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev.1/ Thanks, Laurent Le lun. 17 f?vr. 2020 ? 07:51, Andrew John Hughes > a ?crit : On 13/02/2020 13:25, Laurent Bourg?s wrote: > Please review this 3rd patch to backport the Marlin renderer from jdk9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8144630 > patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch > webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev/ > unshuffled patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/unshuffled/8-m03.8144630.patch > > Changes in RendererStats: > * Fixed import: > -+import sun.awt.util.ThreadGroupUtils; > ++import sun.misc.ThreadGroupUtils; > * Fixed indentation / chunks > > > Best regards, > Laurent > Why was it necessary to fix "indentation / chunks"? I tried applying the 8144630 changeset from OpenJDK 9 and it applied as is, so the only necessary change would seem to be the import. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -- -- Laurent Bourg?s From Martijn.Verburg at microsoft.com Mon Feb 17 22:32:27 2020 From: Martijn.Verburg at microsoft.com (Martijn Verburg) Date: Mon, 17 Feb 2020 22:32:27 +0000 Subject: [EXTERNAL] [JFR] new patch bundle published In-Reply-To: References: Message-ID: We'll build internally this week and let you know! Cheers, Martijn ________________________________ From: Mario Torre Sent: Tuesday, February 18, 2020 00:33 To: jdk8u-dev Cc: Hohensee, Paul ; Martijn Verburg ; Ben Evans ; Marcus Hirt ; Gil Tene ; ???(??) ; Andrey Petushkov Subject: [EXTERNAL] [JFR] new patch bundle published Hi all, I just published a new set of patches to add on top of the latest jdk8u-dev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~neugens%2FJDK8u-JFR.04%2F&data=02%7C01%7Cmartijn.verburg%40microsoft.com%7C3ecfab9d8c8946259e2e08d7b39d57b9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637175360676597799&sdata=YeFGIHWSnpZ3aGePrkBOezPMCo0j5NyMGI7QNrHTdHY%3D&reserved=0 This set includes all the patches currently in the incubator plus a patch to enable the JFR by default (which isn't in the incubator yet, pending discussion on the mailing list). I really appreciate if I could get some feedback (even as additional review eyes) and broader testing. One notable change, this revision contains JDK-8230707, which makes -XX:EnableTracing a no-op; the option is still recognised but it won't print anymore information on the command line (since this is obviously replaced by JFR). Testing, especially for performance regression, is needed and very, very welcomed :) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From joe.darcy at oracle.com Wed Feb 19 05:45:12 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 18 Feb 2020 21:45:12 -0800 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: References: Message-ID: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> Hi Paul, This looks like a spec change to a Java SE API so would be out of bounds for 11u without a maintenance update of Java SE 11. Naoto, do you agree with that analysis? Thanks, -Joe On 2/18/2020 5:44 PM, Hohensee, Paul wrote: > Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 for a backport of JDK-8215181 to jdk11u. It?s identical to the original CSR. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 > > Thanks, > Paul > From naoto.sato at oracle.com Wed Feb 19 13:21:58 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 19 Feb 2020 05:21:58 -0800 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> References: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> Message-ID: Hi Joe, Paul, Yes, I was thinking the same. It is a spec change in 14. Naoto On 2/18/20 9:45 PM, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It?s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >> From joe.darcy at oracle.com Wed Feb 19 16:55:19 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 19 Feb 2020 08:55:19 -0800 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: <8C09617D-2DA2-47F4-B8B7-A453D8991E53@amazon.com> References: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> <8C09617D-2DA2-47F4-B8B7-A453D8991E53@amazon.com> Message-ID: <5cee4ac1-dfcf-6580-71af-6b84ae84a69a@oracle.com> As a practical matter, no. Since a Java SE specification is modified by this changeset, a maintenance review (MR) would be needed for Java SE 11 for this change to go into 11u. HTH, -Joe On 2/19/2020 8:09 AM, Hohensee, Paul wrote: > So, not backportable? > > Paul > > ?On 2/19/20, 5:23 AM, "naoto.sato at oracle.com" wrote: > > Hi Joe, Paul, > > Yes, I was thinking the same. It is a spec change in 14. > > Naoto > > On 2/18/20 9:45 PM, Joe Darcy wrote: > > Hi Paul, > > > > This looks like a spec change to a Java SE API so would be out of bounds > > for 11u without a maintenance update of Java SE 11. > > > > Naoto, do you agree with that analysis? > > > > Thanks, > > > > -Joe > > > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: > >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 > >> for a backport of JDK-8215181 to jdk11u. It?s identical to the > >> original CSR. > >> > >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 > >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 > >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 > >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 > >> > >> Thanks, > >> Paul > >> > > From aph at redhat.com Wed Feb 19 17:11:37 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Feb 2020 17:11:37 +0000 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type In-Reply-To: References: Message-ID: <42c18079-e3d9-7fa0-0e76-845a7dc4231e@redhat.com> On 2/19/20 11:37 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8231430 > https://hg.openjdk.java.net/jdk/jdk/rev/54af3178cdbd > > This is one nasty bug, and it affects 8u as well. Unfortunately, it does not apply cleanly due to > context changes. Also, it misses the introduction of is_reference_type helper (part of much larger > JDK-8230505), and the fatal needs to be wrapped in err_msg to match the old signature. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8231430/webrev.8u.01/ > > Testing: tier1 OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey at azul.com Wed Feb 19 17:35:32 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 19 Feb 2020 17:35:32 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing Message-ID: Hi All, could you please review small patch which aims to disable build of JFR when user requested minimal1 or zero build of VM. JFR code is incompatible with minimal and zero VMs and the proposed behavior is demonstrated by jdk11 implementation. However because the jdk11 build system is completely different in this place I got to invent jdk8-specific implementation. webrev: https://cr.openjdk.java.net/~apetushkov/8239479/ bug: https://bugs.openjdk.java.net/browse/JDK-8239479 Thanks, Andrey From shade at redhat.com Wed Feb 19 17:53:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 18:53:33 +0100 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type In-Reply-To: <42c18079-e3d9-7fa0-0e76-845a7dc4231e@redhat.com> References: <42c18079-e3d9-7fa0-0e76-845a7dc4231e@redhat.com> Message-ID: <7f2d614a-3763-cb7c-c2be-5cf74dc21dab@redhat.com> On 2/19/20 6:11 PM, Andrew Haley wrote: > On 2/19/20 11:37 AM, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8231430 >> https://hg.openjdk.java.net/jdk/jdk/rev/54af3178cdbd >> >> This is one nasty bug, and it affects 8u as well. Unfortunately, it does not apply cleanly due to >> context changes. Also, it misses the introduction of is_reference_type helper (part of much larger >> JDK-8230505), and the fatal needs to be wrapped in err_msg to match the old signature. >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8231430/webrev.8u.01/ >> >> Testing: tier1 > > OK, thanks. Thanks, I added the tags. -- -Aleksey From neugens at redhat.com Wed Feb 19 20:56:07 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 19 Feb 2020 21:56:07 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239476: 8238589: broke windows build by moving OrderedPair Message-ID: Hi all, I would like to propose this fix for the jdk8u-jfr-incubator: http://cr.openjdk.java.net/~neugens/8239476/webrev.00/ When I pushed 8238589 I didn't test on Windows (sorry!) and didn't realise that the position of OrderedPair in the file is actually important for the toolchain. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From ebaron at redhat.com Wed Feb 19 23:22:42 2020 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 19 Feb 2020 18:22:42 -0500 Subject: [8u] RFR Backport 8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature Message-ID: Hi, I'd like to request a review to backport 8079693 to 8u. This fix restores support for curves that were removed by the refactoring in "8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled". It also aids us in backporting "8177334: Update xmldsig implementation to Apache Santuario 2.1.1". Original fix: https://bugs.openjdk.java.net/browse/JDK-8079693 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ad36a27ddf3 The original JDK 9 version of this fix applies cleanly, with one small exception: test/javax/xml/crypto/dsig/GenerationTests: - Bugs listed in jtreg tag differ. -- "8046949: Generify the javax.xml.crypto API" not in 8u, due to API breakage. -- Newer fixes "8074784: Additional tests for XML DSig API" and "8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux" already present in 8u. 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8079693/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_security tests Thanks, Elliott From gnu.andrew at redhat.com Thu Feb 20 02:56:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 02:56:48 +0000 Subject: [8u] RFR Backport 8132130: Some docs cleanup In-Reply-To: References: Message-ID: On 18/02/2020 23:34, Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8132130 to 8u. 8132130 contains > several documentation fixes that allow 8177334 to apply more cleanly. > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8132130 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/339e2b4a5241 > > The JDK 9 changeset did not apply cleanly. Aside from path changes, I > made the following modifications to backport this fix to 8u: > > sun/security/jgss/krb5/Krb5NameElement: > - For equals method, "@param name" already changed to "@param other" by > "8048030: Expectations should be consistent". > > sun/security/krb5/Checksum: > - Updated context for first constructor due to additional Javadoc > introduced by "8229951: Better Ticket Granting Services". > - Doc changes for other constructors in the original fix are no longer > applicable due to further changes from 8229951. > > sun/security/krb5/Realm: > - getRealmsList "@return" tag already corrected by "8133802: replace > some tags (obsolete in html5) in security-libs docs". > > sun/security/krb5/internal/EncKDCRepPart: > - Small spacing change due to "8215032: Support Kerberos cross-realm > referrals (RFC 6806)". > > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8132130/webrev.00/ > > Testing: x86_64 build, jdk_tier1, jdk_security tests > > Thanks, > Elliott > Looks good. Please flag the bug with jdk8u-fix-request. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 02:59:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 02:59:42 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function In-Reply-To: References: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> Message-ID: On 19/02/2020 02:36, Yangfei (Felix) wrote: >> -----Original Message----- >> From: Andrew Hughes [mailto:gnu.andrew at redhat.com] >> Sent: Tuesday, February 18, 2020 8:43 PM >> To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net >> Subject: Re: [8u] RFR 8167409: Invalid value passed to critical JNI function >> >> >> On 03/12/2019 06:11, Yangfei (Felix) wrote: >>> Hi, >>> >>> >>> Please review 8u backport of 8167409. >>> >>> >>> Original bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8167409 >>> >>> http://hg.openjdk.java.net/jdk/jdk/rev/11b8ac93804c >>> >>> >>> Original patch does not apply cleanly to 8u due to path differences and >> missing file. >>> >>> >>> 8u webrev: >>> >>> http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.00/ >>> >>> >>> This updated copyright years for files changed or added. >>> >>> Also added one shell script Test8167409.sh to run the newly added test case >> in the original patch. >>> >>> >>> Testing: Run full jtreg test with a x86-64 release build. >>> >>> Newly add test case fail without the patch and pass with the patch. >>> >> >> Was the script based on one of the existing ones? It looks similar. > > Yes, modified from: hotspot/test/runtime/7107135/Test7107135.sh > Thanks. >> Generally happy with the patch, but would omit the copyright header changes, >> as they are just going to create problems for future backports. > > Do you mean the Copyright years update in these files? > Yes, the addition of 2019 in src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp & test/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java This is appropriate for a new patch, but for a backport, it will create future friction. >> Also, the /runtime should probably be dropped from the test path as other >> tests in 8u aren't under the runtime subdirectory. > > Good suggestion. I can propose a new webrev if you want. > Please. > > Thanks, > Felix > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 03:12:31 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 03:12:31 +0000 Subject: RFR: 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats In-Reply-To: References: <1443241f-cfaf-86f9-f414-2a44e795241f@redhat.com> Message-ID: <9ceb618f-39f2-7036-8f79-6fa6b09ec85c@redhat.com> On 18/02/2020 17:01, Laurent Bourg?s wrote: > Hi Andrew, > > I fixed the patch (in-place) to only fix import, no indentation change: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630.patch > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.03/m03.8144630-webrev.1/ > > Thanks, > Laurent > Thanks. This looks clearer now. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 03:15:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 03:15:45 +0000 Subject: Marlin renderer patches for jdk8u integration In-Reply-To: References: <4EEB666E-6B5A-4BE6-BEB3-76905BCD4772@amazon.com> <34015E1A-99CD-46AC-8493-EA590D8AF445@amazon.com> <6beea6e2-c2a7-3945-2bcd-d37e6b23419d@redhat.com> Message-ID: <4a1d9ecb-8166-3d7f-b1ff-756d6b50f8af@redhat.com> On 19/02/2020 08:13, Laurent Bourg?s wrote: > Hi Andrew, > > As we started this effort to backport Marlin in openjdk 8u 252, I want > this task to be finished as soon as possible.? > I know jd8u roadmap has a short window: RDP at 02.26 in 1 week. As > Marlin renderer is disabled by default in 8u, it does not hurt. This > backport can go on and will be ready in later 8u release. > > Currently m01 & m02 patches are pushed, m03 is in RFR. > > How can we go faster ?? > 1. Maybe I can start several RFR in parallel, but how can I tell > webrev.ksh to make incremental web revs without committing every patch > in my local mercurial repository. > > HG clone is very slow, so I can not do for every patch.? > I tried using a local branch (but jcheck complained, so I disabled it) > but a branch can not be deleted in mercurial. I can use backups (remote > tip) to manually revert / update... > > How do you usually make incremental web revs ? > Please don't. If it's complicated to create webrevs, because they are built on top of an intermediate state, that also suggests it's going to make it complicated and confusing to review. > 2. RFR mails + JBS fix requests are great but this workflow imposes high > latency... Maybe we could group them and follow a schedule: every > wednesday RFR / fix requests must be ready / processed... patches ready > be pushed. I'm not sure how this would be different from what we're already doing. Can you elaborate? > > If possible, could we have a phone call ? > Sure, if that helps. > Thanks, > Laurent Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 03:47:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 03:47:16 +0000 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type In-Reply-To: References: Message-ID: <82101b18-7357-9f86-5962-007ae5193851@redhat.com> On 19/02/2020 11:37, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8231430 > https://hg.openjdk.java.net/jdk/jdk/rev/54af3178cdbd > > This is one nasty bug, and it affects 8u as well. Unfortunately, it does not apply cleanly due to > context changes. Also, it misses the introduction of is_reference_type helper (part of much larger > JDK-8230505), and the fatal needs to be wrapped in err_msg to match the old signature. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8231430/webrev.8u.01/ > > Testing: tier1 > is_reference_type actually seems to be introduced by JDK-8186209 [0] [1] (I wondered about this as 11 doesn't have JDK-8230505) Given I don't see us backporting ConstantDynamic, could we not include that small change to globalDefinitions.hpp in this fix, rather than transposing its body into the if block in src/share/vm/opto/type.cpp? That would also avoid anyone else having to make the same replacement in future backports. Rest looks fine. [0] https://bugs.openjdk.java.net/browse/JDK-8186209 [1] http://hg.openjdk.java.net/jdk/jdk/rev/c4d9d1b08e2e Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:11:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:11:06 +0000 Subject: [8u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) In-Reply-To: References: Message-ID: <1b4ac8d6-7163-2bad-8246-9e163e723749@redhat.com> On 19/02/2020 11:42, Alex Kashchenko wrote: > Please review the backport of JDK-8216472 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 > > Original review thread: > https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html > > Original review thread (continuation): > https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006777.html > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e > > 11u review thread: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002417.html > > > 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/3f41514eef8a > > 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8216472/webrev.00/ > > 8u change is the same as in 11u, it doesn't apply cleanly to 8u because > of different imports and minor code differences in java part. > > Testing: 8u change in this form was included with Red Hat 8u242-windows > release and passed usual release testing. > This looks good to me. I'd still say you should use your OpenJDK username on this commit, even if you're not technically an author for this particular JDK project. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:22:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:22:16 +0000 Subject: [8u] RFR 8191227: Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg() In-Reply-To: References: Message-ID: On 19/02/2020 11:51, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8191227 > https://hg.openjdk.java.net/jdk/jdk/rev/bb957f109a1f > > The patch applies after reshuffling and fuzz. We ship parts of this fix in shenandoah/jdk8u: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011434.html > > I would appreciate reviews w.r.t. its bug tail. It seems to be followed up by JDK-8193699, which > introduced numerous failures in itself. I don't think this fix individually causes those troubles. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8191227/webrev.8u.01/ > > Testing: tier1 > Patch looks fine, just some context differences. I assume the bug tail is more about JDK-8167372: "Add code to check for getting oops while thread is in native" (JDK-8193699 "AArch64: Fails to build after 8167372" is a response to that, and for AArch64, which currently isn't supported in 8u). I can see the merits in backporting that, but I'd wait until the 8u262 cycle so we maximise the time to shake out any issues. This patch seems pretty safe, given the only product build change is to introduce ThreadInVMfromUnknown tiv in ConstantOopWriteValue::print_on(outputStream* st). It's effectively an instance of the bug JDK-8167372 aims to make easier to catch. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:26:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:26:16 +0000 Subject: [8u] RFR 8181872: C1: possible overflow when strength reducing integer multiply by constant In-Reply-To: References: <8270f8b4-89b6-02aa-62c0-16098640baa3@redhat.com> Message-ID: On 19/02/2020 12:18, Aleksey Shipilev wrote: > Replying with bug id in the subject, for archival reasons. > > On 2/19/20 1:17 PM, Aleksey Shipilev wrote: >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8181872 >> https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 >> >> Patch applies cleanly, except that aarch64 and arm is not in 8u, so those hunks are ignored. >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8181872/webrev.8u.01/ >> >> Testing: tier1, affected test (it passes even without the fix, probably because my toolchain does >> not break it) > Looks fine. I assume you'll apply the AArch64 fix after this makes it into aarch64-port/shenandoah-jdk8u? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:29:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:29:29 +0000 Subject: [8u] RFR 8187078: -XX:+VerifyOops finds numerous problems when running JPRT In-Reply-To: References: Message-ID: <759c9765-3d7e-2edd-6137-239b7087a886@redhat.com> On 19/02/2020 12:22, Aleksey Shipilev wrote: > On 2/19/20 1:11 PM, Aleksey Shipilev wrote: >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8187078 >> https://hg.openjdk.java.net/jdk/jdk/rev/8f594f75e054 >> >> The patch applies after reshuffles, except for barrierSetC1.cpp hunk, that is in c1_LIRGenerator.cpp >> in 8u. (It was moved by a huge JDK-8201543 later in 11). > > (sighs) > > 8u webrev: > https://cr.openjdk.java.net/~shade/8187078/webrev.8u.01/ > Looks fine. The context in c1_LIRGenerator.cpp is nearly identical. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:45:31 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:45:31 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: <9ae99166-7cb5-3d7f-235c-df671de6df8b@azul.com> References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> <9ae99166-7cb5-3d7f-235c-df671de6df8b@azul.com> Message-ID: On 19/02/2020 13:00, Andrey Petushkov wrote: > Hi Andrew, > > Uploaded webrev at https://cr.openjdk.java.net/~fijiol/8031126/webrev.00/ > > Thanks, > Andrey > > On 19.02.2020 07:20, Andrew Hughes wrote: >> >> On 31/07/2019 16:23, Andrey Petushkov wrote: >>> Hi Aleksey, >>> >>> I'll do >>> >>> Thanks, >>> Andrey >>> >>>> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: >>>> >>>> On 7/16/19 7:42 PM, Fedor Burdun wrote: >>>>> The issue described in bugs 8031126/8030631 is still reproducible on java8. >>>>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? >>>> This makes sense. Is there anyone from Azul to assist you with following this checklist? >>>> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >>>> >>>> Thanks, >>>> -Aleksey >> Is there a webrev for this backport? >> >> Thanks, > Thanks. Backport looks right, but I think we should probably backport JDK-8036122 first (which includes the changes to proc_stat_path). That should then make this change a clean backport. I take a look at this and get back to you. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:46:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:46:42 +0000 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <0950e7af-19bf-f008-d87d-38892132f2c0@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> <24ca6ca1-3713-525d-a6e6-11e09e5ce484@redhat.com> <6c33df8f-29d6-4260-68a3-5adf44b70a36@redhat.com> <0950e7af-19bf-f008-d87d-38892132f2c0@redhat.com> Message-ID: On 19/02/2020 15:22, Simon Tooke wrote: > I have updated the webrev, preserving the original copyright date (as > modified by the original patch). > > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/03/jdk.03/ > > regards, > > -simon > Thanks, Simon. This looks good now. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 04:55:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 04:55:26 +0000 Subject: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid In-Reply-To: References: <9c16c81e-234c-5de8-2881-05176a46372b@redhat.com> Message-ID: <0dec203c-db9a-84e2-a92a-07dcc7bf8d63@redhat.com> On 19/02/2020 15:50, Yangfei (Felix) wrote: >> -----Original Message----- >> From: Andrew Hughes [mailto:gnu.andrew at redhat.com] >> Sent: Wednesday, February 19, 2020 12:15 PM >> To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net >> Subject: Re: Request for Approval: Backport of 8047212 : >> runtime/ParallelClassLoading/bootstrap/random/inner-complex >> assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is >> invalid >> >> >> >> On 20/08/2019 03:43, Yangfei (Felix) wrote: >>> Hi, >>> >>> >>> >>> May I got review for the backport of 8146792 to 8u master repo please? >>> >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.00/ >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047212 >>> >>> JDK9 Changeset: >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a0c7a69277da >>> >>> >> >> PaddedEnd is introduced by JDK-8049737, which is part of JEP-143, so I agree it >> makes sense to workaround this change rather than backport it. >> The code is essentially the same, minus the wrapping of the ObjectMonitor in >> PaddedEnd. >> >> Some minor issues: >> >> * Empty line lost between: >> >> + oop obj = (oop)mid->object(); >> >> and >> >> + if (obj == NULL) { >> >> * Empty line lost between: >> >> + deflated = deflate_monitor(mid, obj, &FreeHead, &FreeTail); >> >> and >> >> + if (deflated) { >> >> Both are in synchronizer.cpp and cause the diffs to not line up when compared >> with the original 9u changeset. > > Thanks for the careful review. I have updated accordingly. > New webrev: http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.01/ > Please help push it if it's OK to go. > > Best regards, > Felix > Thanks! The revised version is a lot easier to compare :-) I'll push this for you. We should also look at proposing you for 8u committer status, as you already have it for 9+. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 05:04:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 05:04:08 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: References: Message-ID: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> On 19/02/2020 17:35, Andrey Petushkov wrote: > Hi All, > > could you please review small patch which aims to disable build of JFR > when user > requested minimal1 or zero build of VM. JFR code is incompatible with > minimal and zero VMs > and the proposed behavior is demonstrated by jdk11 implementation. > However because the jdk11 > build system is completely different in this place I got to invent > jdk8-specific implementation. > > webrev: https://cr.openjdk.java.net/~apetushkov/8239479/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8239479 > > Thanks, > Andrey > The change itself looks good. However, I'm confused as this seems to be based on top of an --enable-jfr option which is enabled by default. I thought we had decided not to do this just yet? So the default value of enable_jfr here should be no, not auto just yet. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 05:08:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 05:08:46 +0000 Subject: [8u] RFR Backport 8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature In-Reply-To: References: Message-ID: On 19/02/2020 23:22, Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8079693 to 8u. > > This fix restores support for curves that were removed by the > refactoring in "8046724: XML Signature ECKeyValue elements cannot be > marshalled or unmarshalled". It also aids us in backporting "8177334: > Update xmldsig implementation to Apache Santuario 2.1.1". > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8079693 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ad36a27ddf3 > > The original JDK 9 version of this fix applies cleanly, with one small > exception: > > test/javax/xml/crypto/dsig/GenerationTests: > - Bugs listed in jtreg tag differ. > -- "8046949: Generify the javax.xml.crypto API" not in 8u, due to API > breakage. > -- Newer fixes "8074784: Additional tests for XML DSig API" and > "8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux" > already present in 8u. > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8079693/webrev.00/ > > Testing: x86_64 build, jdk_tier1, jdk_security tests > > Thanks, > Elliott > Looks good to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 05:24:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 05:24:10 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: On 07/02/2020 18:10, Andrew John Hughes wrote: > > > On 06/02/2020 15:55, Hohensee, Paul wrote: >> Reviving this one. >> >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808 >> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592 >> Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/ >> >> Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp. >> >> Thanks, >> Paul >> > > Yeah, I've been holding off on this, because it affects downstream > out-of-tree-ports and I was hoping to get the AArch64 port in first. > However, I think that's now looking like something for 8u262. > > I also appreciated, during the recent release processes, that neither 8u > & 11u build with -Werror for me as they stand upstream, so I would like > to see this resolved. I'll take a look at the patch on Monday. > > Thanks, > It looks like the webrev also includes the JDK-8229345 change. Can you do a clean one with just 8062808? Also, I'm looking at 8036122 for another bug, and that also is based on -Wformat=2 being there from 8030350. With 8022263 applied first, it looks like 8022263->8030350->8036122 could be a series of clean backports. So, if you could hold off with this one a little longer until I get those integrated, I think that would help us both. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 20 05:36:58 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Feb 2020 05:36:58 +0000 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? Message-ID: I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, which is a clean backport and a pre-requisite for some later changes. This is a fairly simple patch, basically synchronising the warning logic with the GNU/Linux platform. The patch builds fine with GCC 7 on GNU/Linux, but it would be good if someone could check these additional flags don't break the build on *BSD. Generally, it'd also be good to know who is testing 8u on which platforms for fixes such as this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From felix.yang at huawei.com Thu Feb 20 06:21:23 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 20 Feb 2020 06:21:23 +0000 Subject: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid In-Reply-To: <0dec203c-db9a-84e2-a92a-07dcc7bf8d63@redhat.com> References: <9c16c81e-234c-5de8-2881-05176a46372b@redhat.com> <0dec203c-db9a-84e2-a92a-07dcc7bf8d63@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Thursday, February 20, 2020 12:55 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: Request for Approval: Backport of 8047212 : > runtime/ParallelClassLoading/bootstrap/random/inner-complex > assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is > invalid > > > > Thanks for the careful review. I have updated accordingly. > > New webrev: > > http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.01/ > > Please help push it if it's OK to go. > > > > Best regards, > > Felix > > > > Thanks! The revised version is a lot easier to compare :-) > > I'll push this for you. We should also look at proposing you for 8u committer > status, as you already have it for 9+. Thanks for the help. Having 8u commit right would be much helpful to our work ;-) Best regards, Felix From shade at redhat.com Thu Feb 20 09:01:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 10:01:12 +0100 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type In-Reply-To: <82101b18-7357-9f86-5962-007ae5193851@redhat.com> References: <82101b18-7357-9f86-5962-007ae5193851@redhat.com> Message-ID: <0a7cf8ff-7fcd-b706-8406-cf2e9518c552@redhat.com> On 2/20/20 4:47 AM, Andrew Hughes wrote: > Given I don't see us backporting ConstantDynamic, could we not include > that small change to globalDefinitions.hpp in this fix, rather than > transposing its body into the if block in src/share/vm/opto/type.cpp? Well, other backports we did substituted is_reference_type call with the explicit body. The rest of HS code uses the same pattern (before JDK-8230505), so it is not like we are doing something out of whack. The only valid reason I would see to import is_reference_type here is in case we would backport JDK-8230505 at some point later, which seems very unlikely. We can still do that, if you insist: https://cr.openjdk.java.net/~shade/8231430/webrev.8u.02/ -- Thanks, -Aleksey From shade at redhat.com Thu Feb 20 09:04:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 10:04:04 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239476: 8238589: broke windows build by moving OrderedPair In-Reply-To: References: Message-ID: <18d2d14b-803e-17ae-394d-33da80d22874@redhat.com> On 2/19/20 9:56 PM, Mario Torre wrote: > http://cr.openjdk.java.net/~neugens/8239476/webrev.00/ Looks fine. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 20 10:42:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 11:42:07 +0100 Subject: [8u] RFR 8181872: C1: possible overflow when strength reducing integer multiply by constant In-Reply-To: References: <8270f8b4-89b6-02aa-62c0-16098640baa3@redhat.com> Message-ID: <2a937e06-15db-2892-865d-549d162449db@redhat.com> On 2/20/20 5:26 AM, Andrew Hughes wrote: > On 19/02/2020 12:18, Aleksey Shipilev wrote: >> Replying with bug id in the subject, for archival reasons. >> >> On 2/19/20 1:17 PM, Aleksey Shipilev wrote: >>> Original fix: >>> https://bugs.openjdk.java.net/browse/JDK-8181872 >>> https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 >>> >>> Patch applies cleanly, except that aarch64 and arm is not in 8u, so those hunks are ignored. >>> >>> 8u webrev: >>> https://cr.openjdk.java.net/~shade/8181872/webrev.8u.01/ >>> >>> Testing: tier1, affected test (it passes even without the fix, probably because my toolchain does >>> not break it) > > Looks fine. Thanks, added the tags. > I assume you'll apply the AArch64 fix after this makes it into > aarch64-port/shenandoah-jdk8u? Yes, that is my plan, and that is why issue has 8-aarch64 as affected version, so our tracking shows this as missing backport in aarch64-port. I would prefer to have the test in from upstream before transplanting the hunk to aarch64. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 20 10:43:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 11:43:43 +0100 Subject: [8u] RFR 8187078: -XX:+VerifyOops finds numerous problems when running JPRT In-Reply-To: <759c9765-3d7e-2edd-6137-239b7087a886@redhat.com> References: <759c9765-3d7e-2edd-6137-239b7087a886@redhat.com> Message-ID: <44fc509b-a987-cbbb-b1ba-ad1a7c3e4486@redhat.com> On 2/20/20 5:29 AM, Andrew Hughes wrote: > On 19/02/2020 12:22, Aleksey Shipilev wrote: >> On 2/19/20 1:11 PM, Aleksey Shipilev wrote: >>> Original fix: >>> https://bugs.openjdk.java.net/browse/JDK-8187078 >>> https://hg.openjdk.java.net/jdk/jdk/rev/8f594f75e054 >>> >>> The patch applies after reshuffles, except for barrierSetC1.cpp hunk, that is in c1_LIRGenerator.cpp >>> in 8u. (It was moved by a huge JDK-8201543 later in 11). >> >> (sighs) >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8187078/webrev.8u.01/ >> > > Looks fine. The context in c1_LIRGenerator.cpp is nearly identical. Thanks, added the tags. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 20 10:45:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 11:45:57 +0100 Subject: [8u] RFR 8191227: Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg() In-Reply-To: References: Message-ID: <8b0f0b19-783e-7145-b8ce-58df53e20052@redhat.com> On 2/20/20 5:22 AM, Andrew Hughes wrote: > On 19/02/2020 11:51, Aleksey Shipilev wrote: >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8191227 >> https://hg.openjdk.java.net/jdk/jdk/rev/bb957f109a1f >> >> The patch applies after reshuffling and fuzz. We ship parts of this fix in shenandoah/jdk8u: >> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011434.html >> >> I would appreciate reviews w.r.t. its bug tail. It seems to be followed up by JDK-8193699, which >> introduced numerous failures in itself. I don't think this fix individually causes those troubles. >> >> 8u webrev: >> http://cr.openjdk.java.net/~shade/8191227/webrev.8u.01/ > > Patch looks fine, just some context differences. > > I assume the bug tail is more about JDK-8167372: "Add code to check for > getting oops while thread is in native" (JDK-8193699 "AArch64: Fails to > build after 8167372" is a response to that, and for AArch64, which > currently isn't supported in 8u). I can see the merits in backporting > that, but I'd wait until the 8u262 cycle so we maximise the time to > shake out any issues. Yes. I wanted someone to arrive to the same conclusion. > This patch seems pretty safe, given the only product build change is to > introduce ThreadInVMfromUnknown tiv in > ConstantOopWriteValue::print_on(outputStream* st). It's effectively an > instance of the bug JDK-8167372 aims to make easier to catch. Thanks! I added the tags. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 20 12:29:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 13:29:52 +0100 Subject: [8u] RFR 8229022: BufferedReader performance can be improved by using StringBuilder Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8229022 https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 Patch does not apply cleanly to 8u, because context is different. Reapplying hunks by hand yield this 8u webrev: https://cr.openjdk.java.net/~shade/8229022/webrev.8u.01/ Testing: tier1 -- Thanks, -Aleksey From andrey at azul.com Thu Feb 20 12:38:04 2020 From: andrey at azul.com (Andrey Petushkov) Date: Thu, 20 Feb 2020 15:38:04 +0300 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> Message-ID: <02874dc1-e350-a410-66d4-754a8d97d585@azul.com> On 20.02.2020 08:04, Andrew Hughes wrote: > > On 19/02/2020 17:35, Andrey Petushkov wrote: >> Hi All, >> >> could you please review small patch which aims to disable build of JFR >> when user >> requested minimal1 or zero build of VM. JFR code is incompatible with >> minimal and zero VMs >> and the proposed behavior is demonstrated by jdk11 implementation. >> However because the jdk11 >> build system is completely different in this place I got to invent >> jdk8-specific implementation. >> >> webrev: https://cr.openjdk.java.net/~apetushkov/8239479/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8239479 >> >> Thanks, >> Andrey >> > The change itself looks good. > > However, I'm confused as this seems to be based on top of an > --enable-jfr option which is enabled by default. I thought we had > decided not to do this just yet? > > So the default value of enable_jfr here should be no, not auto just yet. The review is based on the current state of the jdk8u-jfr-incubator repo. So I assume the change of the default value to no did not yet get in. It's of course trivial to make it here but I'd rather not mix these two things in one commit Andrey > > Thanks, From zgu at redhat.com Thu Feb 20 12:44:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 20 Feb 2020 07:44:32 -0500 Subject: [8u] RFR 8229022: BufferedReader performance can be improved by using StringBuilder In-Reply-To: References: Message-ID: <27b16129-3819-a7cf-1e5c-c3f3adc496f0@redhat.com> Looks good to me. -Zhengyu On 2/20/20 7:29 AM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8229022 > https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 > > Patch does not apply cleanly to 8u, because context is different. Reapplying hunks by hand yield > this 8u webrev: > https://cr.openjdk.java.net/~shade/8229022/webrev.8u.01/ > > Testing: tier1 > From neugens at redhat.com Thu Feb 20 12:46:05 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 20 Feb 2020 13:46:05 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> Message-ID: On Thu, Feb 20, 2020 at 6:04 AM Andrew Hughes wrote: > The change itself looks good. > > However, I'm confused as this seems to be based on top of an > --enable-jfr option which is enabled by default. I thought we had > decided not to do this just yet? > > So the default value of enable_jfr here should be no, not auto just yet. Hi Andrew, I pushed this change in the repository after it was reviewed, I thought what you meant was to not merge this into mainline when it was time. So my bad here. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From felix.yang at huawei.com Thu Feb 20 13:24:21 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 20 Feb 2020 13:24:21 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function In-Reply-To: References: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Thursday, February 20, 2020 11:00 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFR 8167409: Invalid value passed to critical JNI function > > > > >> Generally happy with the patch, but would omit the copyright header > >> changes, as they are just going to create problems for future backports. > > > > Do you mean the Copyright years update in these files? > > > > Yes, the addition of 2019 in > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp & > test/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.jav > a > > This is appropriate for a new patch, but for a backport, it will create future > friction. Thanks for explaining this. > >> Also, the /runtime should probably be dropped from the test path as > >> other tests in 8u aren't under the runtime subdirectory. > > > > Good suggestion. I can propose a new webrev if you want. > > > Please. New webrev: http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.01/ Thanks, Felix From shade at redhat.com Thu Feb 20 14:08:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 15:08:08 +0100 Subject: [8u] RFR 8229022: BufferedReader performance can be improved by using StringBuilder In-Reply-To: <27b16129-3819-a7cf-1e5c-c3f3adc496f0@redhat.com> References: <27b16129-3819-a7cf-1e5c-c3f3adc496f0@redhat.com> Message-ID: <483db0b3-486b-dbc1-7758-f5b53fc2c33a@redhat.com> Thanks, added the tags. On 2/20/20 1:44 PM, Zhengyu Gu wrote: > Looks good to me. > > -Zhengyu > > On 2/20/20 7:29 AM, Aleksey Shipilev wrote: >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8229022 >> https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 >> >> Patch does not apply cleanly to 8u, because context is different. Reapplying hunks by hand yield >> this 8u webrev: >> https://cr.openjdk.java.net/~shade/8229022/webrev.8u.01/ -- Thanks, -Aleksey From fedor.burdun at azul.com Thu Feb 20 14:48:54 2020 From: fedor.burdun at azul.com (Fedor) Date: Thu, 20 Feb 2020 17:48:54 +0300 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: References: Message-ID: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> Hello Andrew, As far as I can see OpenJDK 8u build is broken for *BSD targets at the time being. At least I succeed to build JDK for NetBSD 6 only after a bunch of changes in ./make ./hotspot/make and jdk/make. Used compiler is x86_64--netbsd-gcc (NetBSD nb2 20111202) 4.5.3 I've checked the modifications and can say that mentioned JDK-8022263 changeset (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d16be2b85802) doesn't bring new compilation problems for *BSD using GCC. Thanks, Fedor On 20.02.2020 8:36, Andrew Hughes wrote: > I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, which > is a clean backport and a pre-requisite for some later changes. > > This is a fairly simple patch, basically synchronising the warning logic > with the GNU/Linux platform. The patch builds fine with GCC 7 on > GNU/Linux, but it would be good if someone could check these additional > flags don't break the build on *BSD. > > Generally, it'd also be good to know who is testing 8u on which > platforms for fixes such as this. > > Thanks, > From fedor.burdun at azul.com Thu Feb 20 15:41:23 2020 From: fedor.burdun at azul.com (Fedor) Date: Thu, 20 Feb 2020 18:41:23 +0300 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> References: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> Message-ID: macOS build also has been checked: xcodebuild -version Xcode 4.6.2 Build version 4H1003 Toolchain: gcc (GNU Compiler Collection) C Compiler: Version 4.2.1 (at /usr/bin/gcc) C++ Compiler: Version 4.2.1 (at /usr/bin/g++) On 20.02.2020 17:48, Fedor wrote: > Hello Andrew, > > As far as I can see OpenJDK 8u build is broken for *BSD targets at the > time being. > At least I succeed to build JDK for NetBSD 6 only after a bunch of > changes in ./make ./hotspot/make and jdk/make. > Used compiler is x86_64--netbsd-gcc (NetBSD nb2 20111202) 4.5.3 > > I've checked the modifications and can say that mentioned JDK-8022263 > changeset > (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d16be2b85802) doesn't > bring new compilation problems for *BSD using GCC. > > Thanks, > Fedor > > > On 20.02.2020 8:36, Andrew Hughes wrote: >> I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, which >> is a clean backport and a pre-requisite for some later changes. >> >> This is a fairly simple patch, basically synchronising the warning logic >> with the GNU/Linux platform. The patch builds fine with GCC 7 on >> GNU/Linux, but it would be good if someone could check these additional >> flags don't break the build on *BSD. >> >> Generally, it'd also be good to know who is testing 8u on which >> platforms for fixes such as this. >> >> Thanks, >> From akashche at redhat.com Thu Feb 20 19:13:17 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 20 Feb 2020 19:13:17 +0000 Subject: [8u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) In-Reply-To: <1b4ac8d6-7163-2bad-8246-9e163e723749@redhat.com> References: <1b4ac8d6-7163-2bad-8246-9e163e723749@redhat.com> Message-ID: Hi Andrew, On 02/20/2020 04:11 AM, Andrew Hughes wrote: > > > On 19/02/2020 11:42, Alex Kashchenko wrote: >> Please review the backport of JDK-8216472 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 >> >> Original review thread: >> https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html >> >> Original review thread (continuation): >> https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006777.html >> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e >> >> 11u review thread: >> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002417.html >> >> >> 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/3f41514eef8a >> >> 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8216472/webrev.00/ >> >> 8u change is the same as in 11u, it doesn't apply cleanly to 8u because >> of different imports and minor code differences in java part. >> >> Testing: 8u change in this form was included with Red Hat 8u242-windows >> release and passed usual release testing. >> > > This looks good to me. > > I'd still say you should use your OpenJDK username on this commit, even > if you're not technically an author for this particular JDK project. Thanks for the review, I've added 8u fix request to the issue. -- -Alex From xxinliu at amazon.com Thu Feb 20 19:44:05 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 20 Feb 2020 19:44:05 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: <9E52A1F1-47D1-49DF-92B2-DD50349F7511@amazon.com> Hi, Andrew, Here is the old message, but the information is still right. It doesn't contain JDK-8229345. It's almost a clean patch except for perfData.cpp. It's a leftover of JDK-8064811. I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. thanks, --lx ?On 2/19/20, 9:24 PM, "Andrew Hughes" wrote: On 07/02/2020 18:10, Andrew John Hughes wrote: > > > On 06/02/2020 15:55, Hohensee, Paul wrote: >> Reviving this one. >> >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808 >> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592 >> Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/ >> >> Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp. >> >> Thanks, >> Paul >> > > Yeah, I've been holding off on this, because it affects downstream > out-of-tree-ports and I was hoping to get the AArch64 port in first. > However, I think that's now looking like something for 8u262. > > I also appreciated, during the recent release processes, that neither 8u > & 11u build with -Werror for me as they stand upstream, so I would like > to see this resolved. I'll take a look at the patch on Monday. > > Thanks, > It looks like the webrev also includes the JDK-8229345 change. Can you do a clean one with just 8062808? Also, I'm looking at 8036122 for another bug, and that also is based on -Wformat=2 being there from 8030350. With 8022263 applied first, it looks like 8022263->8030350->8036122 could be a series of clean backports. So, if you could hold off with this one a little longer until I get those integrated, I think that would help us both. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From bourges.laurent at gmail.com Thu Feb 20 23:14:08 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 21 Feb 2020 00:14:08 +0100 Subject: RFR: 8144526: Remove Marlin logging use of deleted internal API Message-ID: Please review this 6th patch to backport the Marlin renderer from jdk9. JBS: https://bugs.openjdk.java.net/browse/JDK-8144526 patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/m06.8144526.patch webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/m06.8144526-webrev/ unshuffled patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/unshuffled/8-m06.8144526.patch Changes in MarlinUtils: * Fixed import: --import jdk.internal.misc.JavaLangAccess; --import jdk.internal.misc.SharedSecrets; +-import sun.misc.JavaLangAccess; +-import sun.misc.SharedSecrets; Best regards, Laurent From akozlov at azul.com Fri Feb 21 11:34:22 2020 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 21 Feb 2020 14:34:22 +0300 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: <04281d1c-ae7d-6a64-527e-ffee19da8a30@azul.com> References: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> <7DC7CFE1-6A83-44D3-9A87-876B2B9F7228@amazon.com> <04281d1c-ae7d-6a64-527e-ffee19da8a30@azul.com> Message-ID: On 18.10.2019 15:14, Anton Kozlov wrote: > > On 17.10.2019 14:45, Andrew Dinn wrote: >> backport looks good. > > > On 16.10.2019 22:26, Hohensee, Paul wrote: >> Your backport looks good to me > Alexey recently posted few notes on this backport to JBS [1], refering to discovered regression [2]. I think that discussion should be continued on this alias, where more interested people can follow it. Third-party software assumes JDK implementation details: uses reflection to change private field of system class and depends on subsequent behavior. But it seems we should support they anyway. We can revert to old behavior by reverting the patch. We can invent a new patch which restores lazy initialization checks again, but then we'll need some additional synchronization, previous lazy-init-check was called by synchronized method. For context, discussed bug JDK-8231584 is broader version of JDK-8194653, for which we don't have a fix. Perhaps, we can invent a fix for latter bug instead, involving only specific class loader and/or specific class (which loads a library). The problem is that we don't have a reliable reproducer for JDK-8194653. We have synthetic cases built, which IMHO can be fixed only by a general fix (this one). Thanks, Anton 1: https://bugs.openjdk.java.net/browse/JDK-8231584?focusedCommentId=14318106&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14318106 2: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011026.html From neugens at redhat.com Fri Feb 21 15:16:25 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 21 Feb 2020 16:16:25 +0100 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> Message-ID: Hi Andrew, Can we move this forward? I think we can probably reset the flag when we do the integration, either as part of JDK-8239140 or with a separate bug id. Cheers, Mario On Thu, Feb 20, 2020 at 1:46 PM Mario Torre wrote: > > On Thu, Feb 20, 2020 at 6:04 AM Andrew Hughes wrote: > > > The change itself looks good. > > > > However, I'm confused as this seems to be based on top of an > > --enable-jfr option which is enabled by default. I thought we had > > decided not to do this just yet? > > > > So the default value of enable_jfr here should be no, not auto just yet. > > Hi Andrew, I pushed this change in the repository after it was > reviewed, I thought what you meant was to not merge this into mainline > when it was time. > > So my bad here. > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Fri Feb 21 23:39:09 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 21 Feb 2020 23:39:09 +0000 Subject: 8144526: Remove Marlin logging use of deleted internal API In-Reply-To: References: Message-ID: Looks good. Thanks, Paul From: Laurent Bourg?s Date: Thursday, February 20, 2020 at 3:15 PM To: jdk8u-dev , "Hohensee, Paul" Subject: RFR: 8144526: Remove Marlin logging use of deleted internal API Please review this 6th patch to backport the Marlin renderer from jdk9. JBS: https://bugs.openjdk.java.net/browse/JDK-8144526 patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/m06.8144526.patch webrev: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/m06.8144526-webrev/ unshuffled patch: http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.06/unshuffled/8-m06.8144526.patch Changes in MarlinUtils: * Fixed import: --import jdk.internal.misc.JavaLangAccess; --import jdk.internal.misc.SharedSecrets; +-import sun.misc.JavaLangAccess; +-import sun.misc.SharedSecrets; Best regards, Laurent From adinn at redhat.com Mon Feb 24 11:58:22 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 24 Feb 2020 11:58:22 +0000 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: References: Message-ID: <4001d308-e427-31f4-96ea-13a85d23af13@redhat.com> Hi Mario, n.b. I'm replying to this RFC thread on the grounds that it appears to be the de facto RFR thread for the patch. So,m take this as a final review for whether or not to include the patch into jdk8u-dev. In sum, it's a yes. I have reviewed (by eyeball) the latest set of patches for inclusion of JFR into jdk8u-dev, concentrating on the JVM code in particular. The patch version I used is: http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ The effect on jdk8u is considered in 3 different aspects below. I don't think any aspect leads to cause for concern over committing the backport. 1) Isolation of changes when JFR is excluded at build time Most of the changes to JVM code are only conditionally compiled into the build if enabled at build i.e. with --enable-jfr. However, the patch does still involve changes to the JVM code base that will be compiled into the product even without that option. I am confident that all such changes are trivial and will not affect the behaviour of the JVM. The same conclusion holds for the JDK code. The few changes to JDK runtime code are small additions to the API surface and underlying behaviour. I do not believe they will affect code that is not using the new APIs. 2) Isolation of changes when JFR is included at build time. 2a) Effect on Runtime and App Behaviour As far as functionality is concerned I could only find one circumstance in the JDK code where the presence of JFR might result in noticeably different operation of the application. Code which processes MXBeans may observe the new JFR PlatformMBean and not recognise it. I think that is a low risk issue and delaying the backport is not going to mitigate it significantly (we ca't avoid this possibility and won't find the problem cases until we release a backported version). Other JDK and JVM changes may result in different operation in the underlying called code (e.g. existing trace code has been replaced by JFR code) but I don't believe these differences will change the way the caller operates i.e. I believe they will be semantically neutral to clients. 2b) Effect on Runtime and App performance I could not find any reason to expect any significant performance differences when JFR is included but not started, whether by omitting to start on the command line or via jcmd. The only two points where extra work might be done on a regular basis -- and therefore where a significant impact might be seen on performance -- are the leak profiler (called regularly by the GC) and the various event dispatch calls scattered throughout the JVM code. Both of these short circuit without doing any work unless flight recorder is started either on the command line or via jcmd so the cost is unlikely to be noticed. The event dispatch does involve a small amount of preparatory work (allocate and initialize an event on the stack, test whether it is enabled) but the C compiler ought to optimize most of this cost away and even if it doe snot it should not add much overhead. Of course, there will be an impact on performance when JFR is in use and this may be noticeable. I could not identify any reason to expect the cost of running with JFR on to be significantly higher than when it is used on jdk11. 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 On 30/01/2020 11:37, Mario Torre wrote: > Hi all, > > The moment has finally arrived where we are at the point to request > the big merge. > > Andrew Hughes was kind enough to provide the webrevs and the list of > bugs, I'm going through them now to mark them for the backport request > but I think there is some need for a last batch of testing before we > finally hit the integration button, and we can take the opportunity to > have a final discussion over those patches during the committer's > workshop. > > Before moving on, I wish to thank everyone who was involved in this > effort. This was truly an example in collaboration and was amazing. I > wish to thank in particular: > > Andrey Petushkov > Sanhong Li > Jaroslav Bachorik > Marcus Hirt > Ekaterina Vergizova > Denghui Dong > Martin Balao > Jiri Vanek > Andrew Hughes > Aleksey Shipilev > Andrew Haley > > And everyone else who was involved either directly or indirectly I am > missing from this list, but has supported the efforts with testing, > suggestions and fixes, and that includes of course the original > authors for most of those fixes. > > Also, I wish to thank personally Joe Darcy for his thorough > investigation for the CSR, for his feedback and support. > > This is probably the largest backport attempted so far, so while we > had many eyes and spent many hours testing, we know there is still > work to do. Merging this code this early in the cycle between releases > will give us a chance to iron out existing issues before the April > release. > > Another note, those changes won't enable JFR automatically, the > configure flag --enable-jfr will still need to be passed, without this > OpenJDK binaries won't have JFR. This is done for compatibility and > also as a safety net. > > Ok, without further ado, here's the webrev and the list of changes as > Andrew John Hughes has kindly provided: > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/ > > against jdk8u252-b01 and merge changesets: > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/merge.changeset > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/merge.changeset > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/merge.changeset > > Changes: > - S8003209: JFR events for network utilization > - S8041626: Shutdown tracing event > - S8165675: Trace event for thread park has incorrect unit for timeout > - S8195817: JFR.stop should require name of recording > - S8195818: JFR.start should increase autogenerated name by one > - S8195819: Remove recording=x from jcmd JFR.check output > - S8199712: Flight Recorder > - S8202578: Revisit location for class unload events > - S8202835: jfr/event/os/TestSystemProcess.java fails on missing events > - S8203287: Zero fails to build after JDK-8199712 (Flight Recorder) > - S8203346: JFR: Inconsistent signature of jfr_add_string_constant > - S8203664: JFR start failure after AppCDS archive created with JFR > StartFlightRecording > - S8203921: JFR thread sampling is missing fixes from JDK-8194552 > - S8203929: Limit amount of data for JFR.dump > - S8205516: JFR tool > - S8207392: [PPC64] Implement JFR profiling > - S8207829: FlightRecorderMXBeanImpl is leaking the first classloader > which calls it > - S8209960: -Xlog:jfr* doesn't work with the JFR > - S8210024: JFR calls virtual is_Java_thread from ~Thread() > - S8211239: Build fails without JFR: empty JFR events signatures mismatch > - S8212232: Wrong metadata for the configuration of the cutoff for old > object sample events > - S8213015: Inconsistent settings between JFR.configure and > -XX:FlightRecorderOptions > - S8213421: Line number information for execution samples always 0 > - S8213617: JFR should record the PID of the recorded process > - S8213914: [TESTBUG] Several JFR VM events are not covered by tests > - S8213917: [TESTBUG] Shutdown JFR event is not covered by test > - S8213966: The ZGC JFR events should be marked as experimental > - S8214542: JFR: Old Object Sample event slow on a deep heap in debug > builds > - S8214750: Unnecessary

tags in jfr classes > - S8214896: JFR Tool left files behind > - S8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with > UnsatisfiedLinkError > - S8214925: JFR tool fails to execute > - S8215175: Inconsistencies in JFR event metadata > - S8215237: jdk.jfr.Recording javadoc does not compile > - S8215284: Reduce noise induced by periodic task getFileSize() > - S8215362: JFR GTest JfrTestNetworkUtilization fails > - S8215771: The jfr tool should pretty print reference chains > - S8216064: -XX:StartFlightRecording:settings= doesn't work properly > - S8216486: Possibility of integer overflow in JfrThreadSampler::run() > - S8216559: [JFR] Native libraries not correctly parsed from > /proc/self/maps > - S8216578: Remove unused/obsolete method in JFR code > - S8216995: Clean up JFR command line processing > - S8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due > to process surviving SIGINT > - S8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent > - S8218935: Make jfr strncpy uses GCC 8.x friendly > - S8223147: JFR Backport > - S8223689: Add JFR Thread Sampling Support > - S8223690: Add JFR BiasedLock Event Support > - S8223691: Add JFR G1 Region Type Change Event Support > - S8223692: Add JFR G1 Heap Summary Event Support > - S8224172: assert(jfr_is_event_enabled(id)) failed: invariant > - S8226779: [TESTBUG] Test JFR API from Java agent > - S8227011: Starting a JFR recording in response to JVMTI VMInit and / > or Java agent premain corrupts memory > - S8227605: Kitchensink fails "assert((((klass)->trace_id() & > (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > - S8229366: JFR backport allows unchecked writing to memory > - S8229401: Fix JFR code cache test failures > - S8229708: JFR backport code does not initialize > - S8229873: 8229401 broke jdk8u-jfr-incubator > - S8230448: [test] JFRSecurityTestSuite.java is failing on Windows > - S8230707: JFR related tests are failing > - S8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 > - S8231995: two jtreg tests failed after 8229366 is fixed > - S8233623: Add classpath exception to copyright in > EventHandlerProxyCreator.java file > - S8236002: CSR for JFR backport suggests not leaving out the package-info > - S8236008: Some backup files were accidentally left in the hotspot tree > - S8236074: Missed package-info > - S8236174: Should update javadoc since tags > - S8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport > > Cheers, > Mario > From neugens at redhat.com Mon Feb 24 12:56:12 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2020 13:56:12 +0100 Subject: [RFC]: Integrate jdk8u-jfr-incubator with jdk8u-dev In-Reply-To: <4001d308-e427-31f4-96ea-13a85d23af13@redhat.com> References: <4001d308-e427-31f4-96ea-13a85d23af13@redhat.com> Message-ID: Hi Andrew, Thank you very, very much for this review, I appreciate you taking the time to look at the proposed changes. Regarding the possible compatibility you mentioned due to the mbean interface addition, we did file a CSR for this backport, I think I didn't mention this in my original email so here is the link to it: https://bugs.openjdk.java.net/browse/JDK-8230764 I agree there may be a very low risk of breaking some applications, one of our reasoning during the review process the jdk.management.jfr is not a namespace in JDK8u, so effectively this will appear to applications as any other custom mbean name that may eventually be provided by the client code, I assume that only applications that may scan through the list of available mbeans will notice, but given the namespace is not protected in 8u it won't matter: the bean name won't be available when JFR is not compiled in, and in this case an exception will be thrown, but this is inline with the current specification for all mbeans names when not available. I don't know what the current closed JDK does regarding the mbeans interfaces, I guess in 8 they have a different name, so this maybe an area where application may need to look for two names when trying to enable JFR via JMX, on the other hand, nothing changes for applications that already run on 8 now but don't use JFR on OpenJDK. JDK Mission Control is aware of this however, and is able to start flight recorder without problems, so any application that uses this tool, or uses jcmd, will be automatically fine. Given that jdk.management.jfr is also the standard namespace in 11+ we have the benefit that applications will be compatible across all versions now. We also retained the UnlockCommercialFeatures flag for compatibility (however it does nothing of course). Thanks again for your time and review! Cheers, Mario On Mon, Feb 24, 2020 at 12:58 PM Andrew Dinn wrote: > > Hi Mario, > > n.b. I'm replying to this RFC thread on the grounds that it appears to > be the de facto RFR thread for the patch. So,m take this as a final > review for whether or not to include the patch into jdk8u-dev. In sum, > it's a yes. > > > I have reviewed (by eyeball) the latest set of patches for inclusion of > JFR into jdk8u-dev, concentrating on the JVM code in particular. The > patch version I used is: > > http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ > > The effect on jdk8u is considered in 3 different aspects below. I don't > think any aspect leads to cause for concern over committing the backport. > > 1) Isolation of changes when JFR is excluded at build time > > Most of the changes to JVM code are only conditionally compiled into the > build if enabled at build i.e. with --enable-jfr. However, the patch > does still involve changes to the JVM code base that will be compiled > into the product even without that option. I am confident that all such > changes are trivial and will not affect the behaviour of the JVM. > > The same conclusion holds for the JDK code. The few changes to JDK > runtime code are small additions to the API surface and underlying > behaviour. I do not believe they will affect code that is not using the > new APIs. > > 2) Isolation of changes when JFR is included at build time. > > 2a) Effect on Runtime and App Behaviour > > As far as functionality is concerned I could only find one circumstance > in the JDK code where the presence of JFR might result in noticeably > different operation of the application. Code which processes MXBeans may > observe the new JFR PlatformMBean and not recognise it. I think that is > a low risk issue and delaying the backport is not going to mitigate it > significantly (we ca't avoid this possibility and won't find the problem > cases until we release a backported version). > > Other JDK and JVM changes may result in different operation in the > underlying called code (e.g. existing trace code has been replaced by > JFR code) but I don't believe these differences will change the way the > caller operates i.e. I believe they will be semantically neutral to clients. > > 2b) Effect on Runtime and App performance > > I could not find any reason to expect any significant performance > differences when JFR is included but not started, whether by omitting to > start on the command line or via jcmd. > > The only two points where extra work might be done on a regular basis -- > and therefore where a significant impact might be seen on performance -- > are the leak profiler (called regularly by the GC) and the various event > dispatch calls scattered throughout the JVM code. Both of these short > circuit without doing any work unless flight recorder is started either > on the command line or via jcmd so the cost is unlikely to be noticed. > The event dispatch does involve a small amount of preparatory work > (allocate and initialize an event on the stack, test whether it is > enabled) but the C compiler ought to optimize most of this cost away and > even if it doe snot it should not add much overhead. > > Of course, there will be an impact on performance when JFR is in use and > this may be noticeable. I could not identify any reason to expect the > cost of running with JFR on to be significantly higher than when it is > used on jdk11. > > 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 > > On 30/01/2020 11:37, Mario Torre wrote: > > Hi all, > > > > The moment has finally arrived where we are at the point to request > > the big merge. > > > > Andrew Hughes was kind enough to provide the webrevs and the list of > > bugs, I'm going through them now to mark them for the backport request > > but I think there is some need for a last batch of testing before we > > finally hit the integration button, and we can take the opportunity to > > have a final discussion over those patches during the committer's > > workshop. > > > > Before moving on, I wish to thank everyone who was involved in this > > effort. This was truly an example in collaboration and was amazing. I > > wish to thank in particular: > > > > Andrey Petushkov > > Sanhong Li > > Jaroslav Bachorik > > Marcus Hirt > > Ekaterina Vergizova > > Denghui Dong > > Martin Balao > > Jiri Vanek > > Andrew Hughes > > Aleksey Shipilev > > Andrew Haley > > > > And everyone else who was involved either directly or indirectly I am > > missing from this list, but has supported the efforts with testing, > > suggestions and fixes, and that includes of course the original > > authors for most of those fixes. > > > > Also, I wish to thank personally Joe Darcy for his thorough > > investigation for the CSR, for his feedback and support. > > > > This is probably the largest backport attempted so far, so while we > > had many eyes and spent many hours testing, we know there is still > > work to do. Merging this code this early in the cycle between releases > > will give us a chance to iron out existing issues before the April > > release. > > > > Another note, those changes won't enable JFR automatically, the > > configure flag --enable-jfr will still need to be passed, without this > > OpenJDK binaries won't have JFR. This is done for compatibility and > > also as a safety net. > > > > Ok, without further ado, here's the webrev and the list of changes as > > Andrew John Hughes has kindly provided: > > > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/ > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/ > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/ > > > > against jdk8u252-b01 and merge changesets: > > > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/hotspot/merge.changeset > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/jdk/merge.changeset > > https://cr.openjdk.java.net/~andrew/openjdk8/jfr/root/merge.changeset > > > > Changes: > > - S8003209: JFR events for network utilization > > - S8041626: Shutdown tracing event > > - S8165675: Trace event for thread park has incorrect unit for timeout > > - S8195817: JFR.stop should require name of recording > > - S8195818: JFR.start should increase autogenerated name by one > > - S8195819: Remove recording=x from jcmd JFR.check output > > - S8199712: Flight Recorder > > - S8202578: Revisit location for class unload events > > - S8202835: jfr/event/os/TestSystemProcess.java fails on missing events > > - S8203287: Zero fails to build after JDK-8199712 (Flight Recorder) > > - S8203346: JFR: Inconsistent signature of jfr_add_string_constant > > - S8203664: JFR start failure after AppCDS archive created with JFR > > StartFlightRecording > > - S8203921: JFR thread sampling is missing fixes from JDK-8194552 > > - S8203929: Limit amount of data for JFR.dump > > - S8205516: JFR tool > > - S8207392: [PPC64] Implement JFR profiling > > - S8207829: FlightRecorderMXBeanImpl is leaking the first classloader > > which calls it > > - S8209960: -Xlog:jfr* doesn't work with the JFR > > - S8210024: JFR calls virtual is_Java_thread from ~Thread() > > - S8211239: Build fails without JFR: empty JFR events signatures mismatch > > - S8212232: Wrong metadata for the configuration of the cutoff for old > > object sample events > > - S8213015: Inconsistent settings between JFR.configure and > > -XX:FlightRecorderOptions > > - S8213421: Line number information for execution samples always 0 > > - S8213617: JFR should record the PID of the recorded process > > - S8213914: [TESTBUG] Several JFR VM events are not covered by tests > > - S8213917: [TESTBUG] Shutdown JFR event is not covered by test > > - S8213966: The ZGC JFR events should be marked as experimental > > - S8214542: JFR: Old Object Sample event slow on a deep heap in debug > > builds > > - S8214750: Unnecessary

tags in jfr classes > > - S8214896: JFR Tool left files behind > > - S8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with > > UnsatisfiedLinkError > > - S8214925: JFR tool fails to execute > > - S8215175: Inconsistencies in JFR event metadata > > - S8215237: jdk.jfr.Recording javadoc does not compile > > - S8215284: Reduce noise induced by periodic task getFileSize() > > - S8215362: JFR GTest JfrTestNetworkUtilization fails > > - S8215771: The jfr tool should pretty print reference chains > > - S8216064: -XX:StartFlightRecording:settings= doesn't work properly > > - S8216486: Possibility of integer overflow in JfrThreadSampler::run() > > - S8216559: [JFR] Native libraries not correctly parsed from > > /proc/self/maps > > - S8216578: Remove unused/obsolete method in JFR code > > - S8216995: Clean up JFR command line processing > > - S8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due > > to process surviving SIGINT > > - S8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent > > - S8218935: Make jfr strncpy uses GCC 8.x friendly > > - S8223147: JFR Backport > > - S8223689: Add JFR Thread Sampling Support > > - S8223690: Add JFR BiasedLock Event Support > > - S8223691: Add JFR G1 Region Type Change Event Support > > - S8223692: Add JFR G1 Heap Summary Event Support > > - S8224172: assert(jfr_is_event_enabled(id)) failed: invariant > > - S8226779: [TESTBUG] Test JFR API from Java agent > > - S8227011: Starting a JFR recording in response to JVMTI VMInit and / > > or Java agent premain corrupts memory > > - S8227605: Kitchensink fails "assert((((klass)->trace_id() & > > (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > > - S8229366: JFR backport allows unchecked writing to memory > > - S8229401: Fix JFR code cache test failures > > - S8229708: JFR backport code does not initialize > > - S8229873: 8229401 broke jdk8u-jfr-incubator > > - S8230448: [test] JFRSecurityTestSuite.java is failing on Windows > > - S8230707: JFR related tests are failing > > - S8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 > > - S8231995: two jtreg tests failed after 8229366 is fixed > > - S8233623: Add classpath exception to copyright in > > EventHandlerProxyCreator.java file > > - S8236002: CSR for JFR backport suggests not leaving out the package-info > > - S8236008: Some backup files were accidentally left in the hotspot tree > > - S8236074: Missed package-info > > - S8236174: Should update javadoc since tags > > - S8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport > > > > Cheers, > > Mario > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Feb 24 13:36:12 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2020 14:36:12 +0100 Subject: RFC: JDK8u backport: 8235904: Infinite loop when rendering huge lines Message-ID: Hi all, I would like to backport the following bug to 8u-dev: https://bugs.openjdk.java.net/browse/JDK-8235904 It mostly applies cleanly, there's some changes however, since the original code did have the casting in place so only one line is actually changed: http://cr.openjdk.java.net/~neugens/8235904-jdk8/webrev.00/jdk.changeset Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Feb 24 16:09:51 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2020 17:09:51 +0100 Subject: [JFR incubator] 8239867: correct over use of INCLUDE_JFR macro Message-ID: Hi all, I would like to push the following fix for 8239867: https://bugs.openjdk.java.net/browse/JDK-8239867 http://cr.openjdk.java.net/~neugens/8239867/webrev.00/hotspot.changeset When cleaning up I was overly zealous, the method is actually referenced within jfr even when it's disabled from within an even call, causing a compilation failure. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Mon Feb 24 16:17:13 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Feb 2020 16:17:13 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> Message-ID: <71be322a-c8b7-44fa-b356-d45b83531627@redhat.com> On 2/21/20 3:16 PM, Mario Torre wrote: > Can we move this forward? > > I think we can probably reset the flag when we do the integration, > either as part of JDK-8239140 or with a separate bug id. All of the downstreams known to me want JFR, so it might as well be on by default. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Feb 24 16:39:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 24 Feb 2020 16:39:26 +0000 Subject: RFC: JDK8u backport: 8235904: Infinite loop when rendering huge lines In-Reply-To: References: Message-ID: On 24/02/2020 13:36, Mario Torre wrote: > Hi all, > > I would like to backport the following bug to 8u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8235904 > > It mostly applies cleanly, there's some changes however, since the > original code did have the casting in place so only one line is > actually changed: > > http://cr.openjdk.java.net/~neugens/8235904-jdk8/webrev.00/jdk.changeset > > Cheers, > Mario > Fine by me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Feb 24 16:40:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 24 Feb 2020 16:40:48 +0000 Subject: [JFR incubator] 8239867: correct over use of INCLUDE_JFR macro In-Reply-To: References: Message-ID: <75dcc12e-5cb3-3470-afc7-a994776ce4d4@redhat.com> On 24/02/2020 16:09, Mario Torre wrote: > Hi all, > > I would like to push the following fix for 8239867: > > https://bugs.openjdk.java.net/browse/JDK-8239867 > > http://cr.openjdk.java.net/~neugens/8239867/webrev.00/hotspot.changeset > > When cleaning up I was overly zealous, the method is actually > referenced within jfr even when it's disabled from within an even > call, causing a compilation failure. > > Cheers, > Mario > Looks fine to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Feb 24 17:42:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 24 Feb 2020 17:42:20 +0000 Subject: 8u252 Rampdown & JFR Message-ID: Hi all, First of all, a reminder that 8u is due to rampdown for 8u252 after this Wednesday. Please make sure you either get any patches for that release into 8u-dev over the next couple of days, or start targetting them for 8u262 (the July release) instead. Feel free to ping me if there's a fix that's been missed and needs review/approval to make it in. Thanks to Andrew Dinn for his comprehensive review of the JFR work. To simplify the merge process for this, I propose to integrate it into this rampdown process and the next as follows: 1. 8u & 8u-dev will be frozen for rampdown after Wednesday. Once the appropriate changes are made in the bug database to switch 8u-dev to openjdk8u262, I'll merge the JFR changes there before we open for work on 8u262-b01. 2. JFR is currently enabled by default in the incubator. Once integrated into 8u-dev, I'll disable it by default for the 8u262 release. This will allow the code to be tested and fixed in mainline, but allow some grace before it becomes part of a default build. 3. At rampdown for 8u262 (expected to be the end of May), I'll enable JFR by default in 8u-dev for 8u272. So, in short: 8u252, 2020-04-14: Ramping down now, ALPN + RSA-PSS changes for 8u M3 8u262, 2020-07-14: JFR integrated, but disabled by default 8u272, 2020-10-20: JFR integrated and enabled by default Comments and objections welcome. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Mon Feb 24 17:50:41 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Feb 2020 17:50:41 +0000 Subject: 8u252 Rampdown & JFR In-Reply-To: References: Message-ID: <41fe6d65-4cb7-f4e7-5840-ec96548297b0@redhat.com> On 2/24/20 5:42 PM, Andrew Hughes wrote: > First of all, a reminder that 8u is due to rampdown for 8u252 after this > Wednesday. Please make sure you either get any patches for that release > into 8u-dev over the next couple of days, or start targetting them for > 8u262 (the July release) instead. Feel free to ping me if there's a fix > that's been missed and needs review/approval to make it in. > > Thanks to Andrew Dinn for his comprehensive review of the JFR work. To > simplify the merge process for this, I propose to integrate it into this > rampdown process and the next as follows: > > 1. 8u & 8u-dev will be frozen for rampdown after Wednesday. Once the > appropriate changes are made in the bug database to switch 8u-dev to > openjdk8u262, I'll merge the JFR changes there before we open for work > on 8u262-b01. OK. > 2. JFR is currently enabled by default in the incubator. Once integrated > into 8u-dev, I'll disable it by default for the 8u262 release. This will > allow the code to be tested and fixed in mainline, but allow some grace > before it becomes part of a default build. I'm not entirely convinced by the need to disable it by default because everyone involved in this process will probably enable it in their builds. However, I have no huge objection if that's the way people want to go. I'm not really convinced it's much safer, but it's no big deal either way. > 3. At rampdown for 8u262 (expected to be the end of May), I'll enable > JFR by default in 8u-dev for 8u272. > > So, in short: > > 8u252, 2020-04-14: Ramping down now, ALPN + RSA-PSS changes for 8u M3 > 8u262, 2020-07-14: JFR integrated, but disabled by default > 8u272, 2020-10-20: JFR integrated and enabled by default > > Comments and objections welcome. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Feb 24 19:34:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 24 Feb 2020 19:34:07 +0000 Subject: [8u] RFR 8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type In-Reply-To: <0a7cf8ff-7fcd-b706-8406-cf2e9518c552@redhat.com> References: <82101b18-7357-9f86-5962-007ae5193851@redhat.com> <0a7cf8ff-7fcd-b706-8406-cf2e9518c552@redhat.com> Message-ID: <0150ac57-49eb-ed9f-b8ff-5837c14840e5@redhat.com> On 20/02/2020 09:01, Aleksey Shipilev wrote: > On 2/20/20 4:47 AM, Andrew Hughes wrote: >> Given I don't see us backporting ConstantDynamic, could we not include >> that small change to globalDefinitions.hpp in this fix, rather than >> transposing its body into the if block in src/share/vm/opto/type.cpp? > > Well, other backports we did substituted is_reference_type call with the explicit body. The rest of > HS code uses the same pattern (before JDK-8230505), so it is not like we are doing something out of > whack. The only valid reason I would see to import is_reference_type here is in case we would > backport JDK-8230505 at some point later, which seems very unlikely. > > We can still do that, if you insist: > https://cr.openjdk.java.net/~shade/8231430/webrev.8u.02/ > I'm afraid I don't follow your logic. If other backports have had to make a similar substitution, surely that makes the case for just backporting this little inline function to avoid doing it yet again in future? I don't recall reviewing such backports. I'd probably have said much the same about those. Backporting is tedious enough as it is. I don't see the merit in introducing a difference between the 8u & 11u versions of this fix, when it can be easily resolved with a one-line function. It just creates work for someone who encounters this difference later, and then has to work around it, looking up the definition of is_reference_type in 11u, just to find it matches what has been substituted in 8u. Anyway, I'm happy with the revised webrev. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sergei.tsypanov at yandex.ru Tue Feb 25 12:15:09 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 25 Feb 2020 14:15:09 +0200 Subject: Class.getName() not inlined at concatenation expression Message-ID: <13375671582632909@myt5-bc0f9d8e5f27.qloud-c.yandex.net> Hello, it seems Class.getName() cannot be inlined by optimizing compiler due to inner if-block. As Andrey Pangin explained [1] the reason is profile polution and C1/C2 cannot eliminate inner branch. This results in regression which can be demonstrated by this benchmark: @OutputTimeUnit(TimeUnit.NANOSECONDS) public class BrokenConcatenationBenchmark { @Benchmark public String slow(Data data) { final Class clazz = data.clazz; return "class " + clazz.getName(); } @Benchmark public String fast(Data data) { final Class clazz = data.clazz; final String clazzName = clazz.getName(); return "class " + clazzName; } @State(Scope.Thread) public static class Data { final Class clazz = getClass(); @Setup public void setup() { //explicitly load name via native method Class.getName0() clazz.getName(); } } } I propose to extract Class.getName() expression into a separate variable in some core classes (Class, MethodHandleProxies, Object and URLConnection). This change is useless in later JDKs yet seems to be valid for JDK8 where we do not have indified String concatenation. Patch is attached. 1. https://stackoverflow.com/questions/59157085/java-8-class-getname-slows-down-string-concatenation-chain -------------- next part -------------- A non-text attachment was scrubbed... Name: class_getName.patch Type: text/x-diff Size: 2305 bytes Desc: not available URL: From marcus.hirt at datadoghq.com Tue Feb 25 17:46:51 2020 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 25 Feb 2020 18:46:51 +0100 Subject: [JFR] new patch bundle published In-Reply-To: References: Message-ID: Hi Mario, We'll give it a spin. Kind regards, Marcus On Mon, Feb 17, 2020 at 12:34 PM Mario Torre wrote: > Hi all, > > I just published a new set of patches to add on top of the latest > jdk8u-dev: > > http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ > > This set includes all the patches currently in the incubator plus a > patch to enable the JFR by default (which isn't in the incubator yet, > pending discussion on the mailing list). > > I really appreciate if I could get some feedback (even as additional > review eyes) and broader testing. > > One notable change, this revision contains JDK-8230707, which makes > -XX:EnableTracing a no-op; the option is still recognised but it won't > print anymore information on the command line (since this is obviously > replaced by JFR). > > Testing, especially for performance regression, is needed and very, > very welcomed :) > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > From gromero at linux.vnet.ibm.com Tue Feb 25 22:07:16 2020 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 25 Feb 2020 19:07:16 -0300 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: <9503b430-86a5-2148-9446-341703975c61@linux.vnet.ibm.com> Hello Andrew, Thanks for the review. On 02/18/2020 07:29 AM, Andrew Hughes wrote: > On 27/09/2019 04:31, Gustavo Romero wrote: >> Hi, >> >> Could the following backport for jdk8u be reviewed please? >> >> The original change was mainly written to provide a better >> implementation for >> CRC32 and CRC32C, but it also improved the CRC32 performance in general. >> This >> backport is the first change of a patchset comprised of 4 changes aimed to >> backport all the latest CRC32 missing parts from JDK 11u. >> >> It's a PPC64-only change. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8198894 >> Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0 >> Backport: >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8198894/ >> > > Can we please stick to one change per webrev, please? It makes it > confusing as to what will actually be pushed when a webrev refers to > multiple bugs which are not part of the RFR. Yes, I know. I started the original request with one RFR per change, but then I messed up when I replied Martin the first time and put all the patches on a single RFR related to patch 1/4. Sorry about that. So, just to be clear I started with the following RFRs: [1] [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation [2] [8u] RFR for backport of 8216376 (CRC32 2/4): [PPC64] Possibly unreliable stack frame resizing in template interpreter [3] [8u] RFR for backport of 8216060 (CRC32 3/4): [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays [4] [8u] RFR for backport of 8217459 (CRC32 4/4): [PPC64] Cleanup non-vector version of CRC32 [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035218.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035219.html [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035221.html [4] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035220.html then I replied altogether messing up things in: [5] [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation (v2) [5] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035729.html So in the end the final reviewed webrevs were split up into: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035766.html 1/4 and 2/4 reviewed. Webrevs: 1/4: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/ 2/4: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/ and the remaining ones: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035893.html 3/4 reviewed. Webrev: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v3_/8216060/ https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035894.html 4/4 reviewed. Webrev: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v3_/8217459/ >> It was necessary to backport it to: >> >> - Adapt the file names to OpenJDK 8u > > Fine, and doesn't warrant review on its own. OK. >> - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no >> CRC32C >> - Add Assembler::add_const_optimized() from "8077838: Recent >> developments for ppc" [0] > > Cherry-picking this seems fine as we don't want to force POWER 8 as a > requirement on 8u. OK. >> - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE, >> accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1] > > It seems this fix should be backported as a pre-requisite. Was there a > reason not to? It seems a fairly simple change from a naive perspective. > >> - Adapt signatures for the following functions and their callers, >> accordingly to >> "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], also >> to ease >> subsequent backports in this patchset: >> a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' >> parameter >> b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter >> > > I share Martin's concerns about this. If we must do this, I would prefer > it was done as a separate change. It seems unrelated to the other > changes in 8198894. I'm not sure what you mean here. I've addressed all concerns from Martin. Could you please check the review threads and the webrevs I've pointed out above to see if they address your concern? > A few minor issues: > > * The diff of the macroAssembler_ppc.cpp changes looks different from > the 11u version, though there doesn't seem to be any actual difference. > I don't know if it's possible to line this up better by checking no > empty lines were missed. Could you please try with the version I've pointed out above and if the mismatch still holds point me an example? I know it happens in general, but I fail to see that specific case you've mentioned. > * macroAssembler_ppc.cpp, macroAssembler_ppc.hpp, stubGenerator_ppc.hpp, > stubRoutines_ppc_64.hpp & stubRoutines_ppc_64.cpp include copyright > header changes in the 11u patch which don't appear to be in the 8u > version. Were these already present or simply missed? I missed them. When the changes were pushed to 11u (or so) the Copyright year was 2018. Currently the files on 8u have 2017. Should I update the Copyright dates to 2018 or 2020? Also, do you need a new webrev or can I fix it in place before pushing? Thanks! Best regards, Gustavo From gnu.andrew at redhat.com Wed Feb 26 04:43:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Feb 2020 04:43:34 +0000 Subject: [8u] RFR 8229022: BufferedReader performance can be improved by using StringBuilder In-Reply-To: References: Message-ID: <61beb3a4-a148-c80f-e8a6-abaf3e1c3ee1@redhat.com> On 20/02/2020 12:29, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8229022 > https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 > > Patch does not apply cleanly to 8u, because context is different. Reapplying hunks by hand yield > this 8u webrev: > https://cr.openjdk.java.net/~shade/8229022/webrev.8u.01/ > > Testing: tier1 > The OpenJDK 11 patch applies cleanly (once shuffled), so no need for a review here. Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Feb 26 05:15:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Feb 2020 05:15:07 +0000 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: <02874dc1-e350-a410-66d4-754a8d97d585@azul.com> References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> <02874dc1-e350-a410-66d4-754a8d97d585@azul.com> Message-ID: <43438065-62cf-f0dc-5cf4-845ab21b9a9b@redhat.com> On 20/02/2020 12:38, Andrey Petushkov wrote: > > > On 20.02.2020 08:04, Andrew Hughes wrote: >> >> On 19/02/2020 17:35, Andrey Petushkov wrote: >>> Hi All, >>> >>> could you please review small patch which aims to disable build of JFR >>> when user >>> requested minimal1 or zero build of VM. JFR code is incompatible with >>> minimal and zero VMs >>> and the proposed behavior is demonstrated by jdk11 implementation. >>> However because the jdk11 >>> build system is completely different in this place I got to invent >>> jdk8-specific implementation. >>> >>> webrev: https://cr.openjdk.java.net/~apetushkov/8239479/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8239479 >>> >>> Thanks, >>> Andrey >>> >> The change itself looks good. >> >> However, I'm confused as this seems to be based on top of an >> --enable-jfr option which is enabled by default. I thought we had >> decided not to do this just yet? >> >> So the default value of enable_jfr here should be no, not auto just yet. > The review is based on the current state of the jdk8u-jfr-incubator > repo. So I assume the change > of the default value to no did not yet get in. It's of course trivial to > make it here but I'd rather not > mix these two things in one commit > > Andrey >> >> Thanks, > > Right, I was under the impression the default was still to off, so was surprised by the context. Please push this as is to the incubator. We'll be disabling by default for the first CPU cycle (8u262) as mentioned in my e-mail yesterday [0]. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011266.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrey at azul.com Wed Feb 26 08:28:56 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 26 Feb 2020 11:28:56 +0300 Subject: [JFR: jdk8u-jfr-incubator] RFR: JDK-8239479: minimal1 and zero builds are failing In-Reply-To: <43438065-62cf-f0dc-5cf4-845ab21b9a9b@redhat.com> References: <075e9d8f-8a2d-2491-8bf4-5911f1ad8057@redhat.com> <02874dc1-e350-a410-66d4-754a8d97d585@azul.com> <43438065-62cf-f0dc-5cf4-845ab21b9a9b@redhat.com> Message-ID: Hi Andrew! Pushed yesterday :) Waiting for merge into 8u-dev to happen Thank you, Andrey On 26.02.2020 08:15, Andrew Hughes wrote: > > On 20/02/2020 12:38, Andrey Petushkov wrote: >> >> On 20.02.2020 08:04, Andrew Hughes wrote: >>> On 19/02/2020 17:35, Andrey Petushkov wrote: >>>> Hi All, >>>> >>>> could you please review small patch which aims to disable build of JFR >>>> when user >>>> requested minimal1 or zero build of VM. JFR code is incompatible with >>>> minimal and zero VMs >>>> and the proposed behavior is demonstrated by jdk11 implementation. >>>> However because the jdk11 >>>> build system is completely different in this place I got to invent >>>> jdk8-specific implementation. >>>> >>>> webrev: https://cr.openjdk.java.net/~apetushkov/8239479/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8239479 >>>> >>>> Thanks, >>>> Andrey >>>> >>> The change itself looks good. >>> >>> However, I'm confused as this seems to be based on top of an >>> --enable-jfr option which is enabled by default. I thought we had >>> decided not to do this just yet? >>> >>> So the default value of enable_jfr here should be no, not auto just yet. >> The review is based on the current state of the jdk8u-jfr-incubator >> repo. So I assume the change >> of the default value to no did not yet get in. It's of course trivial to >> make it here but I'd rather not >> mix these two things in one commit >> >> Andrey >>> Thanks, >> > Right, I was under the impression the default was still to off, so was > surprised by the context. > > Please push this as is to the incubator. We'll be disabling by default > for the first CPU cycle (8u262) as mentioned in my e-mail yesterday [0]. > > [0] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011266.html From zgu at redhat.com Wed Feb 26 19:22:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Feb 2020 14:22:45 -0500 Subject: [8u] 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area Message-ID: <05bcccc6-6945-bd60-f738-d14ffea8dab0@redhat.com> Hi, I would like to downport this patch to 8u, as this bug is visible to users [1]. Original bug: https://bugs.openjdk.java.net/browse/JDK-8234270 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee The original patch does not apply cleanly. 1) File location mismatches 1) Arena implementation resides in allocation.cpp 2) Test library naming and locations 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8234270/8u/webrev.00/ Test: runtime/NMT on Linux x86_64. Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039964.html From mbalao at redhat.com Wed Feb 26 23:14:59 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 26 Feb 2020 20:14:59 -0300 Subject: Java 8 - pkcs11 threads hanging In-Reply-To: <63feb83a-b6b8-d7b2-93b2-a4a107523aea@redhat.com> References: <63feb83a-b6b8-d7b2-93b2-a4a107523aea@redhat.com> Message-ID: <5f1ecf84-0170-02af-374f-756cb8fb14a7@redhat.com> Hello Andra, I've moved this discussion from discuss at ... to jdk8u-dev at ... As Aleksey pointed out, the change in behavior you noticed in 8u is due to the backport of JDK-6913047 [1] and the followup-fixes. There is a release note here [2]. This issue has been around for a while, and we finally got it fixed in 8u232. Regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-6913047 [2] - https://bugs.openjdk.java.net/browse/JDK-8215018 On 2/26/20 1:12 PM, Aleksey Shipilev wrote: > On 2/26/20 4:51 PM, Andra Bennett wrote: >> Our application has upgraded from Open JDK 8 191 to JDK 8 232 and one of >> the issues we were previously seeing - namely threads locking up in our >> application when creating message signatures in a multithreaded environment >> using Sun PKCS11 provider - has been mitigated. >> >> We know javax.crypto.Mac is no thread safe so we always created a new >> instance. However, at a certain thread count our application would just >> freeze (easily reproducible in a more focused unit test). > > Have you posted that reproducer somewhere? > >> We would like to see if there was a set of changes that would have targeted >> pkcs11 threads hanging on PKCS11 create/destroy object threads, e.g. >> >> sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method) >> sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1138) >> sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1114) >> sun.security.pkcs11.SessionKeyRef.(P11Key.java:1129) >> sun.security.pkcs11.P11Key.(P11Key.java:119) >> sun.security.pkcs11.P11Key$P11SecretKey.(P11Key.java:405) >> sun.security.pkcs11.P11Key.secretKey(P11Key.java:292) >> sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:267) >> sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:175) >> sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:111) >> sun.security.pkcs11.P11Mac.engineInit(P11Mac.java:206) >> javax.crypto.Mac.chooseProvider(Mac.java:350) > > These are PKCS11-related fixes in OpenJDK 8u: > https://bugs.openjdk.java.net/browse/JDK-8220513 > https://bugs.openjdk.java.net/browse/JDK-8216597 > https://bugs.openjdk.java.net/browse/JDK-6913047 > From gnu.andrew at redhat.com Thu Feb 27 05:01:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 05:01:29 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <9503b430-86a5-2148-9446-341703975c61@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> <9503b430-86a5-2148-9446-341703975c61@linux.vnet.ibm.com> Message-ID: <33c8eb7a-776f-039c-f656-5f9edcd4d6f0@redhat.com> On 25/02/2020 22:07, Gustavo Romero wrote: > Hello Andrew, > > Thanks for the review. > > > On 02/18/2020 07:29 AM, Andrew Hughes wrote: >> On 27/09/2019 04:31, Gustavo Romero wrote: >>> Hi, >>> >>> Could the following backport for jdk8u be reviewed please? >>> >>> The original change was mainly written to provide a better >>> implementation for >>> CRC32 and CRC32C, but it also improved the CRC32 performance in general. >>> This >>> backport is the first change of a patchset comprised of 4 changes >>> aimed to >>> backport all the latest CRC32 missing parts from JDK 11u. >>> >>> It's a PPC64-only change. >>> >>> Bug???? : https://bugs.openjdk.java.net/browse/JDK-8198894 >>> Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0 >>> Backport: >>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8198894/ >>> >> >> Can we please stick to one change per webrev, please? It makes it >> confusing as to what will actually be pushed when a webrev refers to >> multiple bugs which are not part of the RFR. > > Yes, I know. I started the original request with one RFR per change, but > then I > messed up when I replied Martin the first time and put all the patches on a > single RFR related to patch 1/4. Sorry about that. > > So, just to be clear I started with the following RFRs: > > [1] [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic > vector CRC implementation > [2] [8u] RFR for backport of 8216376 (CRC32 2/4): [PPC64] Possibly > unreliable stack frame resizing in template interpreter > [3] [8u] RFR for backport of 8216060 (CRC32 3/4): [PPC64] Vector CRC > implementation should be used by interpreter and be faster for short arrays > [4] [8u] RFR for backport of 8217459 (CRC32 4/4): [PPC64] Cleanup > non-vector version of CRC32 > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035218.html > > [2] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035219.html > > [3] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035221.html > > [4] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035220.html > > > then I replied altogether messing up things in: > > [5] [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic > vector CRC implementation (v2) > > [5] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035729.html > > > So in the end the final reviewed webrevs were split up into: > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035766.html > > 1/4 and 2/4 reviewed. Webrevs: > > 1/4: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8198894/ > 2/4: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v2/8216376/ > > and the remaining ones: > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035893.html > > 3/4 reviewed. Webrev: > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v3_/8216060/ > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/035894.html > > 4/4 reviewed. Webrev: > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/v3_/8217459/ > > >>> It was necessary to backport it to: >>> >>> - Adapt the file names to OpenJDK 8u >> >> Fine, and doesn't warrant review on its own. > > OK. > > >>> - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no >>> CRC32C >>> - Add Assembler::add_const_optimized() from "8077838: Recent >>> developments for ppc" [0] >> >> Cherry-picking this seems fine as we don't want to force POWER 8 as a >> requirement on 8u. > > OK. > > >>> - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE, >>> ?? accordingly to fix in "8190781: ppc64 + s390: Fix >>> CriticalJNINatives" [1] >> >> It seems this fix should be backported as a pre-requisite. Was there a >> reason not to? It seems a fairly simple change from a naive perspective. >> >>> - Adapt signatures for the following functions and their callers, >>> accordingly to >>> ?? "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], >>> also >>> to ease >>> ?? subsequent backports in this patchset: >>> ??? a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' >>> parameter >>> ??? b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' >>> parameter >>> >> >> I share Martin's concerns about this. If we must do this, I would prefer >> it was done as a separate change. It seems unrelated to the other >> changes in 8198894. > > I'm not sure what you mean here. I've addressed all concerns from > Martin. Could > you please check the review threads and the webrevs I've pointed out > above to > see if they address your concern? > > >> A few minor issues: >> >> * The diff of the macroAssembler_ppc.cpp changes looks different from >> the 11u version, though there doesn't seem to be any actual difference. >> I don't know if it's possible to line this up better by checking no >> empty lines were missed. > > Could you please try with the version I've pointed out above and if the > mismatch > still holds point me an example? I know it happens in general, but I fail > to see that specific case you've mentioned. > > >> * macroAssembler_ppc.cpp, macroAssembler_ppc.hpp, stubGenerator_ppc.hpp, >> stubRoutines_ppc_64.hpp & stubRoutines_ppc_64.cpp include copyright >> header changes in the 11u patch which don't appear to be in the 8u >> version. Were these already present or simply missed? > > I missed them. When the changes were pushed to 11u (or so) the Copyright > year > was 2018. Currently the files on 8u have 2017. Should I update the > Copyright > dates to 2018 or 2020? Also, do you need a new webrev or can I fix it in > place > before pushing? > > > Thanks! > > Best regards, > Gustavo > Ok, I think it would be good if you just posted a new RFR with the correct webrev for just 8198894. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 27 05:04:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 05:04:03 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function In-Reply-To: References: <5ff397ee-d27e-6135-a1bc-2c834e91fc66@redhat.com> Message-ID: <8b63e4b6-0460-e00f-bc48-b4df77bc6bc8@redhat.com> On 20/02/2020 13:24, Yangfei (Felix) wrote: >> -----Original Message----- >> From: Andrew Hughes [mailto:gnu.andrew at redhat.com] >> Sent: Thursday, February 20, 2020 11:00 AM >> To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net >> Subject: Re: [8u] RFR 8167409: Invalid value passed to critical JNI function >> >> >> >>>> Generally happy with the patch, but would omit the copyright header >>>> changes, as they are just going to create problems for future backports. >>> >>> Do you mean the Copyright years update in these files? >>> >> >> Yes, the addition of 2019 in >> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp & >> test/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.jav >> a >> >> This is appropriate for a new patch, but for a backport, it will create future >> friction. > > Thanks for explaining this. > >>>> Also, the /runtime should probably be dropped from the test path as >>>> other tests in 8u aren't under the runtime subdirectory. >>> >>> Good suggestion. I can propose a new webrev if you want. >>> >> Please. > > New webrev: http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.01/ > > Thanks, > Felix > Thanks. This looks good now. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 27 05:27:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 05:27:57 +0000 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: References: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> Message-ID: <49c99071-a72b-6fd3-c038-781109d4e9e2@redhat.com> On 20/02/2020 15:41, Fedor wrote: > macOS build also has been checked: > > xcodebuild -version > Xcode 4.6.2 > Build version 4H1003 > > Toolchain: gcc (GNU Compiler Collection) > C Compiler:? Version 4.2.1 (at /usr/bin/gcc) > C++ Compiler:? Version 4.2.1 (at /usr/bin/g++) > > > On 20.02.2020 17:48, Fedor wrote: >> Hello Andrew, >> >> As far as I can see OpenJDK 8u build is broken for *BSD targets at the >> time being. >> At least I succeed to build JDK for NetBSD 6 only after a bunch of >> changes in ./make ./hotspot/make and jdk/make. >> Used compiler is x86_64--netbsd-gcc (NetBSD nb2 20111202) 4.5.3 >> >> I've checked the modifications and can say that mentioned JDK-8022263 >> changeset >> (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d16be2b85802) >> doesn't bring new compilation problems for *BSD using GCC. >> >> Thanks, >> Fedor >> >> >> On 20.02.2020 8:36, Andrew Hughes wrote: >>> I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, which >>> is a clean backport and a pre-requisite for some later changes. >>> >>> This is a fairly simple patch, basically synchronising the warning logic >>> with the GNU/Linux platform. The patch builds fine with GCC 7 on >>> GNU/Linux, but it would be good if someone could check these additional >>> flags don't break the build on *BSD. >>> >>> Generally, it'd also be good to know who is testing 8u on which >>> platforms for fixes such as this. >>> >>> Thanks, >>> > Hi Fedor, Thanks for doing this testing. It's much appreciated. Did the build succeed on Mac OS? I expect that's the only *BSD platform that's seen much maintenance for 8u and I'm not sure who builds it regularly now either :( I'd be interested in the failures for NetBSD. Maybe there is an existing fix for them we can backport or a new patch we can apply. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 27 06:59:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 06:59:22 +0000 Subject: 8u252 Rampdown; Repositories FROZEN Message-ID: <242b7f31-49f9-737e-14a9-67129149414b@redhat.com> Rampdown for the 8u252 release is now taking place. Please do NOT commit to either the 8u or 8u-dev forests. Development of 8u252 will continue in the 8u forest. This will re-open once 8u252-b05 is tested and tagged. Commits to this forest can then take place when a bug has the label jdk8u-critical-yes, following a successful jdk8u-critical-request. Development of 8u262 will start shortly in the 8u-dev forest. Once 8u-dev is switched to tag bugs with the openjdk8u262 release in the bug database, I will merge JFR and re-open 8u-dev for work on this release. Keep an eye on your e-mail for further announcements. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From fedor.burdun at azul.com Thu Feb 27 17:59:26 2020 From: fedor.burdun at azul.com (Fedor) Date: Thu, 27 Feb 2020 20:59:26 +0300 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: <49c99071-a72b-6fd3-c038-781109d4e9e2@redhat.com> References: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> <49c99071-a72b-6fd3-c038-781109d4e9e2@redhat.com> Message-ID: <2724298f-860b-af89-d36b-3283e4349a01@azul.com> Hi Andrew! > Did the build succeed on Mac OS? I expect that's the only *BSD platform > that's seen much maintenance for 8u and I'm not sure who builds it > regularly now either :( Mac OS build succeed with the next toolchain: > On 20/02/2020 15:41, Fedor wrote: >> macOS build also has been checked: >> >> xcodebuild -version >> Xcode 4.6.2 >> Build version 4H1003 >> >> Toolchain: gcc (GNU Compiler Collection) >> C Compiler: Version 4.2.1 (at /usr/bin/gcc) >> C++ Compiler: Version 4.2.1 (at /usr/bin/g++) Azul builds 8u macOS binaries regularly. (https://www.azul.com/downloads/zulu-community/?&version=java-8-lts&os=&os=macos&architecture=x86-64-bit&package=jdk) > I'd be interested in the failures for NetBSD. Maybe there is an existing > fix for them we can backport or a new patch we can apply. Unfortunately there is not existing patch at the time being. (at least I failed to find one) I'm trying to fix NetBSD related bugs right now, but work is in the middle: several of bugs are in progress, and some clean-up is required. If there is interest in this activity I can share my results a little bit later. (Do I need to file bug in JBS for that, or just post webrevs?) Thanks, Fedor On 27.02.2020 8:27, Andrew Hughes wrote: > > > On 20/02/2020 15:41, Fedor wrote: >> macOS build also has been checked: >> >> xcodebuild -version >> Xcode 4.6.2 >> Build version 4H1003 >> >> Toolchain: gcc (GNU Compiler Collection) >> C Compiler:? Version 4.2.1 (at /usr/bin/gcc) >> C++ Compiler:? Version 4.2.1 (at /usr/bin/g++) >> >> >> On 20.02.2020 17:48, Fedor wrote: >>> Hello Andrew, >>> >>> As far as I can see OpenJDK 8u build is broken for *BSD targets at the >>> time being. >>> At least I succeed to build JDK for NetBSD 6 only after a bunch of >>> changes in ./make ./hotspot/make and jdk/make. >>> Used compiler is x86_64--netbsd-gcc (NetBSD nb2 20111202) 4.5.3 >>> >>> I've checked the modifications and can say that mentioned JDK-8022263 >>> changeset >>> (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d16be2b85802) >>> doesn't bring new compilation problems for *BSD using GCC. >>> >>> Thanks, >>> Fedor >>> >>> >>> On 20.02.2020 8:36, Andrew Hughes wrote: >>>> I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, which >>>> is a clean backport and a pre-requisite for some later changes. >>>> >>>> This is a fairly simple patch, basically synchronising the warning logic >>>> with the GNU/Linux platform. The patch builds fine with GCC 7 on >>>> GNU/Linux, but it would be good if someone could check these additional >>>> flags don't break the build on *BSD. >>>> >>>> Generally, it'd also be good to know who is testing 8u on which >>>> platforms for fixes such as this. >>>> >>>> Thanks, >>>> >> > > Hi Fedor, > > Thanks for doing this testing. It's much appreciated. > > Did the build succeed on Mac OS? I expect that's the only *BSD platform > that's seen much maintenance for 8u and I'm not sure who builds it > regularly now either :( > > I'd be interested in the failures for NetBSD. Maybe there is an existing > fix for them we can backport or a new patch we can apply. > > Thanks, > From stooke at redhat.com Thu Feb 27 18:51:30 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 27 Feb 2020 13:51:30 -0500 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: <2724298f-860b-af89-d36b-3283e4349a01@azul.com> References: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> <49c99071-a72b-6fd3-c038-781109d4e9e2@redhat.com> <2724298f-860b-af89-d36b-3283e4349a01@azul.com> Message-ID: <3f3efa25-eb6d-07e5-c25f-93341d964870@redhat.com> On 2020-02-27 12:59 p.m., Fedor wrote: > Hi Andrew! > > > Did the build succeed on Mac OS? I expect that's the only *BSD platform > > that's seen much maintenance for 8u and I'm not sure who builds it > > regularly now either :( > Mac OS build succeed with the next toolchain: > > > On 20/02/2020 15:41, Fedor wrote: > >> macOS build also has been checked: > >> > >> xcodebuild -version > >> Xcode 4.6.2 > >> Build version 4H1003 > >> > >> Toolchain: gcc (GNU Compiler Collection) > >> C Compiler:? Version 4.2.1 (at /usr/bin/gcc) > >> C++ Compiler:? Version 4.2.1 (at /usr/bin/g++) > > Azul builds 8u macOS binaries regularly. > (https://www.azul.com/downloads/zulu-community/?&version=java-8-lts&os=&os=macos&architecture=x86-64-bit&package=jdk) > > > I'd be interested in the failures for NetBSD. Maybe there is an > existing > > fix for them we can backport or a new patch we can apply. > Unfortunately there is not existing patch at the time being. (at least > I failed to find one) > I'm trying to fix NetBSD related bugs right now, but work is in the > middle: several of bugs are in progress, and some clean-up is required. > If there is interest in this activity I can share my results a little > bit later. (Do I need to file bug in JBS for that, or just post webrevs?) > > Thanks, > Fedor > There is an on-going effort to modernize the macOS toolchain; see https://github.com/stooke/jdk8u-xcode10, and https://bugs.openjdk.java.net/browse/JDK-8226288 The results of the patches in that repo are a functioning JDK8 built with the latest XCode, but it has a few? tier1 jtreg failures (that appear in some later JDKs too). I will resubmit an updated webrev n the next few days; several companies have expressed interest in getting it done, but right now we're in rampdown. -Simon > > > On 27.02.2020 8:27, Andrew Hughes wrote: >> >> >> On 20/02/2020 15:41, Fedor wrote: >>> macOS build also has been checked: >>> >>> xcodebuild -version >>> Xcode 4.6.2 >>> Build version 4H1003 >>> >>> Toolchain: gcc (GNU Compiler Collection) >>> C Compiler:? Version 4.2.1 (at /usr/bin/gcc) >>> C++ Compiler:? Version 4.2.1 (at /usr/bin/g++) >>> >>> >>> On 20.02.2020 17:48, Fedor wrote: >>>> Hello Andrew, >>>> >>>> As far as I can see OpenJDK 8u build is broken for *BSD targets at the >>>> time being. >>>> At least I succeed to build JDK for NetBSD 6 only after a bunch of >>>> changes in ./make ./hotspot/make and jdk/make. >>>> Used compiler is x86_64--netbsd-gcc (NetBSD nb2 20111202) 4.5.3 >>>> >>>> I've checked the modifications and can say that mentioned JDK-8022263 >>>> changeset >>>> (http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d16be2b85802) >>>> doesn't bring new compilation problems for *BSD using GCC. >>>> >>>> Thanks, >>>> Fedor >>>> >>>> >>>> On 20.02.2020 8:36, Andrew Hughes wrote: >>>>> I'm looking at https://bugs.openjdk.java.net/browse/JDK-8022263, >>>>> which >>>>> is a clean backport and a pre-requisite for some later changes. >>>>> >>>>> This is a fairly simple patch, basically synchronising the warning >>>>> logic >>>>> with the GNU/Linux platform. The patch builds fine with GCC 7 on >>>>> GNU/Linux, but it would be good if someone could check these >>>>> additional >>>>> flags don't break the build on *BSD. >>>>> >>>>> Generally, it'd also be good to know who is testing 8u on which >>>>> platforms for fixes such as this. >>>>> >>>>> Thanks, >>>>> >>> >> >> Hi Fedor, >> >> Thanks for doing this testing. It's much appreciated. >> >> Did the build succeed on Mac OS? I expect that's the only *BSD platform >> that's seen much maintenance for 8u and I'm not sure who builds it >> regularly now either :( >> >> I'd be interested in the failures for NetBSD. Maybe there is an existing >> fix for them we can backport or a new patch we can apply. >> >> Thanks, >> > From stooke at redhat.com Thu Feb 27 19:55:47 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 27 Feb 2020 14:55:47 -0500 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: <9d63b366-0b17-ef04-30da-15e9fd3a4f68@redhat.com> I have not heard back, and had put this on the back burner for a while. Due to renewed interest expressed to me privately, I would like to resubmit this RFR, updated to the latest JDK and macOS build environment. Updated webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/01/ The result of this build does not perfectly pass jtreg tier1, but there are only a few failures, which appear in more recent JDKs using the same toolchain. I would like to (and invite others to) address the tier 1 failures separately; I suspect there will be more participation if the JDK builds cleanly on Catalina using JDK 11.? Eventually, I hope it will even run faster!. Some of the upcoming RFRs (to address tier 1) appear in https://github.com/stooke/jdk8u-xcode10/tree/master/jdk8u-patch I know we are in rampdown now, but I think it's as good a time as any to decide if this can get in for the following release. Thank you for your time, -Simon On 2019-09-20 4:42 p.m., Derek Keeler wrote: > I'd been over-optimistic in my estimate and haven't gotten our > pipeline in a state where it runs the AdoptOpenJDK tests completely > quite yet. > > However, the build works just fine, and many of the tests do complete > successfully. > > I'll follow up with more detailed results next week. > > -Derek > > ------------------------------------------------------------------------ > *From:* Simon Tooke > *Sent:* September 18, 2019 5:43 AM > *To:* Derek Keeler ; > jdk8u-dev at openjdk.java.net ; build-dev > > *Subject:* Re: [8u] RFR 8226288 - Upgrade to XCode 10+ for building > JDK 8u and 11u > > > On 9/17/2019 1:31 PM, Derek Keeler wrote: >> Hi build-dev friends! >> >> I'm Derek Keeler,?the infrastructure lead on the Java Platform team >> within?Microsoft, working with the AdoptOpenJDK's George Adams and >> John Oliver. >> >> Simon, I have pulled down your jdk8u patches and have built them >> against macOS Mojave (with a good amount of help from George and John). > Hi, and thanks for your interest. >> >> Currently, the build succeeds! >> >> I am planning to throw the entire AdoptOpenJDK test roster against it >> sometime today/tomorrow. >> >> I will let you know what I find as a result of those tests, and what >> if anything I had to do in order to get things up and running. > > Yes, please. Also any difficulties you had with the initial script or > instructions; I know there was a syntax error that I just fixed. > > -Simon > >> >> -Derek >> >> >> ------------------------------------------------------------------------ >> *From:* build-dev >> on behalf of Simon Tooke >> >> *Sent:* September 13, 2019 7:05 AM >> *To:* jdk8u-dev at openjdk.java.net >> ; >> build-dev >> >> *Subject:* [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK >> 8u and 11u >> Hello all, >> >> This is a request for review of my patch to enable building 8u with >> modern (9,10,11) Xcode versions on macOS.? I've received a few recent >> enquiries so I thought I'd submit this. >> >> When I first created this patch is was more for convenience, but soon >> macOS will require applications to be "notarized", which cannot be done >> with the old version of Xcode.? This will become mandatory long before >> 8u is due to retire [1]. >> >> This patch is not intended to remove the current ability to build 8u on >> the current supported build platform. >> >> I have used the patch with Xcode 9,10 and a beta of 11, and used the >> resultant JDK to build Graal. >> >> I have not build a JDK using the old Xcode and this patch; my intent was >> to ensure this was still possible. >> >> There is some information available on my GitHub page: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 >> >> >> Issue: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 >> >> >> Webrev: >> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 >> >> >> Previous discussion: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 >> >> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 >> >> >> Thank you for your time, >> >> -Simon >> >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 >> >> From gnu.andrew at redhat.com Thu Feb 27 20:24:43 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 20:24:43 +0000 Subject: JDK-8022263: use same Clang warnings on BSD as on Linux - Any *BSD testers? In-Reply-To: <2724298f-860b-af89-d36b-3283e4349a01@azul.com> References: <8a473c4f-6836-aba5-b1e1-a56c908b4c94@azul.com> <49c99071-a72b-6fd3-c038-781109d4e9e2@redhat.com> <2724298f-860b-af89-d36b-3283e4349a01@azul.com> Message-ID: <6320b0d4-4642-cfb4-d475-f8d6bc05600f@redhat.com> On 27/02/2020 17:59, Fedor wrote: > Hi Andrew! > >> Did the build succeed on Mac OS? I expect that's the only *BSD platform >> that's seen much maintenance for 8u and I'm not sure who builds it >> regularly now either :( > Mac OS build succeed with the next toolchain: > >> On 20/02/2020 15:41, Fedor wrote: >>> macOS build also has been checked: >>> >>> xcodebuild -version >>> Xcode 4.6.2 >>> Build version 4H1003 >>> >>> Toolchain: gcc (GNU Compiler Collection) >>> C Compiler:? Version 4.2.1 (at /usr/bin/gcc) >>> C++ Compiler:? Version 4.2.1 (at /usr/bin/g++) > > Azul builds 8u macOS binaries regularly. > (https://www.azul.com/downloads/zulu-community/?&version=java-8-lts&os=&os=macos&architecture=x86-64-bit&package=jdk) > > >> I'd be interested in the failures for NetBSD. Maybe there is an existing >> fix for them we can backport or a new patch we can apply. > Unfortunately there is not existing patch at the time being. (at least I > failed to find one) > I'm trying to fix NetBSD related bugs right now, but work is in the > middle: several of bugs are in progress, and some clean-up is required. > If there is interest in this activity I can share my results a little > bit later. (Do I need to file bug in JBS for that, or just post webrevs?) > > Thanks, > Fedor > > I'd say just posting a patch at first is fine. We can develop that into a bug or series of bugs as necessary. Do you know if later OpenJDK releases work? I'd prefer we backport fixes rather than creating something unique to 8u where possible. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Feb 27 20:47:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 20:47:00 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: <9d63b366-0b17-ef04-30da-15e9fd3a4f68@redhat.com> References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> <9d63b366-0b17-ef04-30da-15e9fd3a4f68@redhat.com> Message-ID: On 27/02/2020 19:55, Simon Tooke wrote: > I have not heard back, and had put this on the back burner for a while. > > > Due to renewed interest expressed to me privately, I would like to > resubmit this RFR, updated to the latest JDK and macOS build environment. > > > Updated webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/01/ > > > The result of this build does not perfectly pass jtreg tier1, but there > are only a few failures, which appear in more recent JDKs using the same > toolchain. > > > I would like to (and invite others to) address the tier 1 failures > separately; I suspect there will be more participation if the JDK builds > cleanly on Catalina using JDK 11.? Eventually, I hope it will even run > faster!. > > > Some of the upcoming RFRs (to address tier 1) appear in > https://github.com/stooke/jdk8u-xcode10/tree/master/jdk8u-patch > > > I know we are in rampdown now, but I think it's as good a time as any to > decide if this can get in for the following release. > > > Thank you for your time, > > -Simon > > > I recall this from the first time around. My immediate thought is that this seems to be a new bug that hasn't yet been applied anywhere. Does trunk not already work with XCode 10+? If so, we should be backporting appropriate changes from there, not creating something new for 8u. I believe part of the problem here is newer versions of CLang. Could some of that testing not be done with CLang on GNU/Linux, so more people can participate in getting this fixed? A good starting point seems to be JDK-8019470 [0]. This is actually on the Oracle parity list for 8u252, but no-one seems to have attempted the backport. I'm not sure of the relevance of rampdown to this. This wouldn't be something approved for 8u252 at this stage. 8u-dev will be available for commits again as soon as the bug system is switched over & JFR is merged. [0] https://bugs.openjdk.java.net/browse/JDK-8019470 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From stooke at redhat.com Thu Feb 27 22:09:41 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 27 Feb 2020 17:09:41 -0500 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> <9d63b366-0b17-ef04-30da-15e9fd3a4f68@redhat.com> Message-ID: On 2020-02-27 3:47 p.m., Andrew Hughes wrote: > > On 27/02/2020 19:55, Simon Tooke wrote: >> I have not heard back, and had put this on the back burner for a while. >> >> >> Due to renewed interest expressed to me privately, I would like to >> resubmit this RFR, updated to the latest JDK and macOS build environment. >> >> >> Updated webrev: >> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/01/ >> >> >> The result of this build does not perfectly pass jtreg tier1, but there >> are only a few failures, which appear in more recent JDKs using the same >> toolchain. >> >> >> I would like to (and invite others to) address the tier 1 failures >> separately; I suspect there will be more participation if the JDK builds >> cleanly on Catalina using JDK 11.? Eventually, I hope it will even run >> faster!. >> >> >> Some of the upcoming RFRs (to address tier 1) appear in >> https://github.com/stooke/jdk8u-xcode10/tree/master/jdk8u-patch >> >> >> I know we are in rampdown now, but I think it's as good a time as any to >> decide if this can get in for the following release. >> >> >> Thank you for your time, >> >> -Simon >> >> >> > I recall this from the first time around. > > My immediate thought is that this seems to be a new bug that hasn't yet > been applied anywhere. Does trunk not already work with XCode 10+? If > so, we should be backporting appropriate changes from there, not > creating something new for 8u. > > I believe part of the problem here is newer versions of CLang. Could > some of that testing not be done with CLang on GNU/Linux, so more people > can participate in getting this fixed? A backport of 8019470, for example includes macos-specific code; notable a call to xcode-select, so a test on GNU/Linux would not work.? It's also unclear what internal changes Apple has made to their version of LLVM, and one of my fixes is definitely compiler-dependent.? In addition, future backports proposed will explicitly disable optimization of some files because of compiler bugs; this would be very version-dependent. > > A good starting point seems to be JDK-8019470 [0]. This is actually on > the Oracle parity list for 8u252, but no-one seems to have attempted the > backport. I actually just tried the backport; it does solve a couple of issues, but doesn't remove all of the Xcode version checks (so a build won't happen), and based on prior experience, the JDK that comes out will crash due to other fixes not being present, fixes that are present in my patch. The Oracle backport, therefore, probably has more changes than in a simple backport of 8019470, as does my patch.? What I would like to do is incorporate the default toolchain setting if Xcode version > 5. If you want, I can submit my backport, then rebase my patch on top of that. As for the other content of my webrev, it is pulled together from a series of partial webrevs in higher-level JDKs, and my own work.? Backporting the entirety of some of those webrevs is infeasible - what was a one-liner becomes many hundreds of lines, for example in one case.? It is my belief that, although it is desirable to backport most fixes in their entirety, sometimes the less disruptive option is the better one. (an example: my patch changes about 15 lines, taken from this changeset: http://hg.openjdk.java.net/jdk/jdk/rev/75aa3e39d02c) I appreciate the intent, and in other cases have happily corrected patches to ensure increased compatiblity with future downport work, but I suspect in this case, the opposite is true. Regards, -Simon > > I'm not sure of the relevance of rampdown to this. This wouldn't be > something approved for 8u252 at this stage. 8u-dev will be available > for commits again as soon as the bug system is switched over & JFR is > merged. Yes, you're right.? It is irrelevant. > > [0] https://bugs.openjdk.java.net/browse/JDK-8019470 > > Thanks, From luoziyi at amazon.com Fri Feb 28 01:33:31 2020 From: luoziyi at amazon.com (Luo, Ziyi) Date: Fri, 28 Feb 2020 01:33:31 +0000 Subject: [JFR] new patch bundle published In-Reply-To: References: Message-ID: <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> Hi Mario, Amazon JDK team tested your JFR patches and found 1 failure & 1 error in Jtreg JDK test suite. The build platform is RHEL5 x64, test platform is CentOS 6. FAILED: jdk/jfr/event/io/TestInstrumentation.java (jtr snippet attached) Error: jdk/jfr/event/sampling/TestNative.java The second test requires a native test dependency. Test passed after manually compiling the library and setting up the test native path. Cheers, Ziyi ?On 2/17/20, 3:34 AM, "jdk8u-dev on behalf of Mario Torre" wrote: Hi all, I just published a new set of patches to add on top of the latest jdk8u-dev: http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ This set includes all the patches currently in the incubator plus a patch to enable the JFR by default (which isn't in the incubator yet, pending discussion on the mailing list). I really appreciate if I could get some feedback (even as additional review eyes) and broader testing. One notable change, this revision contains JDK-8230707, which makes -XX:EnableTracing a no-op; the option is still recognised but it won't print anymore information on the command line (since this is obviously replaced by JFR). Testing, especially for performance regression, is needed and very, very welcomed :) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From denghui.ddh at alibaba-inc.com Fri Feb 28 03:24:29 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 28 Feb 2020 11:24:29 +0800 Subject: =?UTF-8?B?UmU6IFtKRlJdIG5ldyBwYXRjaCBidW5kbGUgcHVibGlzaGVk?= In-Reply-To: <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> References: , <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> Message-ID: <1ad8343f-64f3-4d87-9a5d-dac83d0545d5.denghui.ddh@alibaba-inc.com> Hi, jdk/jfr/event/io/TestInstrumentation was unstable now, we can backport JDK-8202142 to fix this problem. Thanks, Denghui Dong ------------------------------------------------------------------ From:Luo, Ziyi Send Time:2020?2?28?(???) 09:33 To:Mario Torre Cc:jdk8u-dev Subject:Re: [JFR] new patch bundle published Hi Mario, Amazon JDK team tested your JFR patches and found 1 failure & 1 error in Jtreg JDK test suite. The build platform is RHEL5 x64, test platform is CentOS 6. FAILED: jdk/jfr/event/io/TestInstrumentation.java (jtr snippet attached) Error: jdk/jfr/event/sampling/TestNative.java The second test requires a native test dependency. Test passed after manually compiling the library and setting up the test native path. Cheers, Ziyi On 2/17/20, 3:34 AM, "jdk8u-dev on behalf of Mario Torre" wrote: Hi all, I just published a new set of patches to add on top of the latest jdk8u-dev: http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ This set includes all the patches currently in the incubator plus a patch to enable the JFR by default (which isn't in the incubator yet, pending discussion on the mailing list). I really appreciate if I could get some feedback (even as additional review eyes) and broader testing. One notable change, this revision contains JDK-8230707, which makes -XX:EnableTracing a no-op; the option is still recognised but it won't print anymore information on the command line (since this is obviously replaced by JFR). Testing, especially for performance regression, is needed and very, very welcomed :) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From vkempik at azul.com Fri Feb 28 09:14:29 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 28 Feb 2020 09:14:29 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: Hello Are you sure it?s needed for jdk8 ? Notarization requires sdk of version at least 10.9 This can be achieved using xcode 4.3.x together with 10.9 sdk (either copy 10.l9 sdk from xcode5 or use systemwide sdk if build host is 10.9) and patching two lines in jdk8?s make files. Going to clang may have many undesired consequences, for example https://bugs.openjdk.java.net/browse/JDK-8234963 Example of the patch to build jdk8 with gcc-llvm and sdk 10.9: hotspot: $ hg diff diff -r 3c35d9ae7194 make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Thu Feb 20 15:54:10 2020 +0300 +++ b/make/bsd/makefiles/gcc.make Wed Feb 26 14:06:16 2020 +0300 @@ -344,7 +344,7 @@ # if built on a newer version of the OS. # The expected format is X.Y.Z ifeq ($(MACOSX_VERSION_MIN),) - MACOSX_VERSION_MIN=10.7.0 + MACOSX_VERSION_MIN=10.9.0 endif # The macro takes the version with no dots, ex: 1070 CFLAGS += -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) \ os-x-10:hotspot dmitry$ cd .. $ hg diff diff -r d8c00a997c65 common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 Thu Feb 20 15:54:10 2020 +0300 +++ b/common/autoconf/flags.m4 Wed Feb 26 14:06:22 2020 +0300 @@ -633,7 +633,7 @@ # newer than the given OS version and makes the linked binaries compatible # even if built on a newer version of the OS. # The expected format is X.Y.Z - MACOSX_VERSION_MIN=10.7.0 + MACOSX_VERSION_MIN=10.9.0 AC_SUBST(MACOSX_VERSION_MIN) # The macro takes the version with no dots, ex: 1070 diff -r d8c00a997c65 common/autoconf/generated-configure.sh --- a/common/autoconf/generated-configure.sh Thu Feb 20 15:54:10 2020 +0300 +++ b/common/autoconf/generated-configure.sh Wed Feb 26 14:06:22 2020 +0300 @@ -4396,7 +4396,7 @@ #CUSTOM_AUTOCONF_INCLUDE # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1580709484 +DATE_WHEN_GENERATED=1582708947 ############################################################################### # @@ -42159,7 +42159,7 @@ # newer than the given OS version and makes the linked binaries compatible # even if built on a newer version of the OS. # The expected format is X.Y.Z - MACOSX_VERSION_MIN=10.7.0 + MACOSX_VERSION_MIN=10.9.0 # The macro takes the version with no dots, ex: 1070 Thanks, Vladimir > 13 ????. 2019 ?., ? 17:05, Simon Tooke ???????(?): > > Hello all, > > This is a request for review of my patch to enable building 8u with > modern (9,10,11) Xcode versions on macOS. I've received a few recent > enquiries so I thought I'd submit this. > > When I first created this patch is was more for convenience, but soon > macOS will require applications to be "notarized", which cannot be done > with the old version of Xcode. This will become mandatory long before > 8u is due to retire [1]. > > This patch is not intended to remove the current ability to build 8u on > the current supported build platform. > > I have used the patch with Xcode 9,10 and a beta of 11, and used the > resultant JDK to build Graal. > > I have not build a JDK using the old Xcode and this patch; my intent was > to ensure this was still possible. > > There is some information available on my GitHub page: > https://github.com/stooke/jdk8u-xcode10 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8226288 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/ > > Previous discussion: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html > > Thank you for your time, > > -Simon > > > [1] > https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution From neugens at redhat.com Fri Feb 28 10:16:14 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 28 Feb 2020 11:16:14 +0100 Subject: [JFR] new patch bundle published In-Reply-To: <1ad8343f-64f3-4d87-9a5d-dac83d0545d5.denghui.ddh@alibaba-inc.com> References: <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> <1ad8343f-64f3-4d87-9a5d-dac83d0545d5.denghui.ddh@alibaba-inc.com> Message-ID: Thanks for testing! I'll backport JDK-8202142 once the patch has been integrated directly into the jdk8u-dev. We need to look more closely at the TestNative.java to see what's up, do you have a patch for that already? The JTreg should have all the necessary detail for the native library to be compiled. Cheers, Mario On Fri, Feb 28, 2020 at 4:25 AM Denghui Dong wrote: > > Hi, > jdk/jfr/event/io/TestInstrumentation was unstable now, we can backport JDK-8202142 to fix this problem. > > Thanks, > Denghui Dong > > ------------------------------------------------------------------ > From:Luo, Ziyi > Send Time:2020?2?28?(???) 09:33 > To:Mario Torre > Cc:jdk8u-dev > Subject:Re: [JFR] new patch bundle published > > Hi Mario, > > Amazon JDK team tested your JFR patches and found 1 failure & 1 error in Jtreg JDK test suite. The build platform is RHEL5 x64, test platform is CentOS 6. > > FAILED: jdk/jfr/event/io/TestInstrumentation.java (jtr snippet attached) > Error: jdk/jfr/event/sampling/TestNative.java > > The second test requires a native test dependency. Test passed after manually compiling the library and setting up the test native path. > > Cheers, > Ziyi > > On 2/17/20, 3:34 AM, "jdk8u-dev on behalf of Mario Torre" wrote: > > Hi all, > > I just published a new set of patches to add on top of the latest jdk8u-dev: > > http://cr.openjdk.java.net/~neugens/JDK8u-JFR.04/ > > This set includes all the patches currently in the incubator plus a > patch to enable the JFR by default (which isn't in the incubator yet, > pending discussion on the mailing list). > > I really appreciate if I could get some feedback (even as additional > review eyes) and broader testing. > > One notable change, this revision contains JDK-8230707, which makes > -XX:EnableTracing a no-op; the option is still recognised but it won't > print anymore information on the command line (since this is obviously > replaced by JFR). > > Testing, especially for performance regression, is needed and very, > very welcomed :) > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Feb 28 12:27:42 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 28 Feb 2020 13:27:42 +0100 Subject: [JFR] new patch bundle published In-Reply-To: References: <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> <1ad8343f-64f3-4d87-9a5d-dac83d0545d5.denghui.ddh@alibaba-inc.com> Message-ID: On Fri, Feb 28, 2020 at 11:16 AM Mario Torre wrote: > > Thanks for testing! > > I'll backport JDK-8202142 once the patch has been integrated directly > into the jdk8u-dev. > > We need to look more closely at the TestNative.java to see what's up, > do you have a patch for that already? The JTreg should have all the > necessary detail for the native library to be compiled. To clarify, this fails for me in every version of the JDK, not just 8u+JFR. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From stooke at redhat.com Fri Feb 28 13:36:08 2020 From: stooke at redhat.com (Simon Tooke) Date: Fri, 28 Feb 2020 08:36:08 -0500 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: <64cf1fd1-24b3-9f27-9183-d6593fbc7dbd@redhat.com> On 2020-02-28 4:14 a.m., Vladimir Kempik wrote: > Hello > > Are you sure it?s needed for jdk8 ? The intent isn't to replace gcc builds with clang builds at this time.? It's to make 8u more accessible for developers to work on. Xcode 4 doesn't run on the latest versions of macos, and I doubt that the latest Apple hardware runs a version of macos that supports it. JDK8 will be supported for quite a few year to come, and I believe once the issues with Clang are worked out it may become the preferred production build, but not yet. > > Notarization requires sdk of version at least 10.9 > > This can be achieved using xcode 4.3.x together with 10.9 sdk (either > copy 10.l9 sdk from xcode5 or use systemwide sdk if build host is > 10.9) and patching two lines in jdk8?s make files. This is not really a solution long term; see above.? This may work for notarization > > Going to clang may have many?undesired consequences, for example > https://bugs.openjdk.java.net/browse/JDK-8234963 Yes, there are other issues too.? I would argue that adding clang buildability to jdk8 increases the pool of developers that can work to improve both jdk8 and LLVM. > > Example of the patch to build jdk8 with gcc-llvm and sdk 10.9: This doesn't meet the goals of my RFR, which is to add the ability to build a reasonable quality macos JDK8 with the latest toolchain, and then improve the quality with later backports as they are found. > > hotspot: > $ hg diff > *diff -r 3c35d9ae7194 make/bsd/makefiles/gcc.make* > *--- a/make/bsd/makefiles/gcc.make ? ? ? Thu Feb 20 15:54:10 2020 +0300* > *+++ b/make/bsd/makefiles/gcc.make ? ? ? Wed Feb 26 14:06:16 2020 +0300* > @@ -344,7 +344,7 @@ > # if built on a newer version of the OS. > # The expected format is X.Y.Z > ifeq ($(MACOSX_VERSION_MIN),) > -? ? MACOSX_VERSION_MIN=10.7.0 > +? ? MACOSX_VERSION_MIN=10.9.0 > endif > # The macro takes the version with no dots, ex: 1070 > CFLAGS += -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst > .,,$(MACOSX_VERSION_MIN)) \ > os-x-10:hotspot dmitry$ cd .. > $ hg diff > *diff -r d8c00a997c65 common/autoconf/flags.m4* > *--- a/common/autoconf/flags.m4? Thu Feb 20 15:54:10 2020 +0300* > *+++ b/common/autoconf/flags.m4? Wed Feb 26 14:06:22 2020 +0300* > @@ -633,7 +633,7 @@ > ? ? # newer than the given OS version and makes the linked binaries > compatible > ? ? # even if built on a newer version of the OS. > ? ? # The expected format is X.Y.Z > - MACOSX_VERSION_MIN=10.7.0 > + MACOSX_VERSION_MIN=10.9.0 > ? ? AC_SUBST(MACOSX_VERSION_MIN) > > > ? ? # The macro takes the version with no dots, ex: 1070 > *diff -r d8c00a997c65 common/autoconf/generated-configure.sh* > *--- a/common/autoconf/generated-configure.sh? ? Thu Feb 20 15:54:10 > 2020 +0300* > *+++ b/common/autoconf/generated-configure.sh? ? Wed Feb 26 14:06:22 > 2020 +0300* > @@ -4396,7 +4396,7 @@ > ?#CUSTOM_AUTOCONF_INCLUDE > > > ?# Do not change or remove the following line, it is needed for > consistency checks: > -DATE_WHEN_GENERATED=1580709484 > +DATE_WHEN_GENERATED=1582708947 > > > ?############################################################################### > ?# > @@ -42159,7 +42159,7 @@ > ? ? # newer than the given OS version and makes the linked binaries > compatible > ? ? # even if built on a newer version of the OS. > ? ? # The expected format is X.Y.Z > - MACOSX_VERSION_MIN=10.7.0 > + MACOSX_VERSION_MIN=10.9.0 > > > > ? ? # The macro takes the version with no dots, ex: 1070 > > Thanks, Vladimir > >> 13 ????. 2019 ?., ? 17:05, Simon Tooke > > ???????(?): >> >> Hello all, >> >> This is a request for review of my patch to enable building 8u with >> modern (9,10,11) Xcode versions on macOS.? I've received a few recent >> enquiries so I thought I'd submit this. >> >> When I first created this patch is was more for convenience, but soon >> macOS will require applications to be "notarized", which cannot be done >> with the old version of Xcode.? This will become mandatory long before >> 8u is due to retire [1]. >> >> This patch is not intended to remove the current ability to build 8u on >> the current supported build platform. >> >> I have used the patch with Xcode 9,10 and a beta of 11, and used the >> resultant JDK to build Graal. >> >> I have not build a JDK using the old Xcode and this patch; my intent was >> to ensure this was still possible. >> >> There is some information available on my GitHub page: >> https://github.com/stooke/jdk8u-xcode10 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8226288 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/ >> >> Previous discussion: >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html >> >> Thank you for your time, >> >> -Simon >> >> >> [1] >> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution > From stooke at redhat.com Fri Feb 28 18:06:03 2020 From: stooke at redhat.com (Simon Tooke) Date: Fri, 28 Feb 2020 13:06:03 -0500 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants Message-ID: Hello, I would like to request approval to backport of JDK-8152545 (Use preprocessor instead of compiling a program to generate native nio constants) to jdk8u for buildability reasons.? I've personally encountered toolchains where the current solution doesn't build. I had to modify the original webrev to get rid of the SO_REUSEPORT definition, as it isn't supported in JDK8. I've tested this on Windows and macos. Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 Modified webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 Thank you for your time, -Simon From dcherepanov at azul.com Fri Feb 28 18:11:56 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Fri, 28 Feb 2020 21:11:56 +0300 Subject: [8u] RFR 8180032 Unaligned pointer dereference in ClassFileParser Message-ID: <0f375ff3-5293-4266-ad4e-634c3ff91978@azul.com> Please review the following backport for 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8180032 Original: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/4b93e1b1d5b7 Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8180032/webrev.v0/ The original patch does not apply cleanly. Here's the list of additional changes for this backport patch. src/cpu/aarch64/vm/bytes_aarch64.hpp src/cpu/arm/vm/bytes_arm.hpp src/cpu/s390/vm/bytes_s390.hpp The files above are missing in 8u, the changes ignored. src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/classFileStream.hpp There was a cleanup in the hotspot files. It's done by https://bugs.openjdk.java.net/browse/JDK-8140485 which seems to be too massive to be backported and seems redundant. The patch for JDK-8140485 changed the context in 10 (e.g. added const modifier) so I manually re-applied the changes. src/share/vm/utilities/bytes.hpp This umbrella header was added in 9 by https://bugs.openjdk.java.net/browse/JDK-8049325. This patch also seems optional for this backport. So I backport'ed only relevant parts (added bytes.hpp and updated #include directives in affected files) to 8u as a part of this change. Built on Win/Mac/Linux/Solaris. Running hotspot runtime regression tests doesn't reveal any issue, full regression testing is in progress. Thanks, Dmitry From gnu.andrew at redhat.com Fri Feb 28 18:45:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Feb 2020 18:45:14 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> <9d63b366-0b17-ef04-30da-15e9fd3a4f68@redhat.com> Message-ID: <5f62811a-5bf0-6637-ba9b-43821a5e7888@redhat.com> On 27/02/2020 22:09, Simon Tooke wrote: > snip... >> >> I believe part of the problem here is newer versions of CLang. Could >> some of that testing not be done with CLang on GNU/Linux, so more people >> can participate in getting this fixed? > A backport of 8019470, for example includes macos-specific code; notable > a call to xcode-select, so a test on GNU/Linux would not work.? It's > also unclear what internal changes Apple has made to their version of > LLVM, and one of my fixes is definitely compiler-dependent.? In > addition, future backports proposed will explicitly disable optimization > of some files because of compiler bugs; this would be very > version-dependent. Sure. I wasn't suggesting it would replace testing on Mac OS. But there's a lot of common ground here that could be covered by getting a Clang build on GNU/Linux working first. >> >> A good starting point seems to be JDK-8019470 [0].? This is actually on >> the Oracle parity list for 8u252, but no-one seems to have attempted the >> backport. > > I actually just tried the backport; it does solve a couple of issues, > but doesn't remove all of the Xcode version checks (so a build won't > happen), and based on prior experience, the JDK that comes out will > crash due to other fixes not being present, fixes that are present in my > patch. > > The Oracle backport, therefore, probably has more changes than in a > simple backport of 8019470, as does my patch.? What I would like to do > is incorporate the default toolchain setting if Xcode version > 5. > > If you want, I can submit my backport, then rebase my patch on top of that. > I'm not suggesting JDK-8019470 was a replacement for your webrev. I identified it from looking at your webrev and tracing back the changes. So, yes, that should be backported first rather than swallowed into a fix under a different bug ID. > As for the other content of my webrev, it is pulled together from a > series of partial webrevs in higher-level JDKs, and my own work.? > Backporting the entirety of some of those webrevs is infeasible - what > was a one-liner becomes many hundreds of lines, for example in one > case.? It is my belief that, although it is desirable to backport most > fixes in their entirety, sometimes the less disruptive option is the > better one. > > (an example: my patch changes about 15 lines, taken from this changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/75aa3e39d02c) > > I appreciate the intent, and in other cases have happily corrected > patches to ensure increased compatiblity with future downport work, but > I suspect in this case, the opposite is true. Sure, but that's something to consider on a case-by-case basis. For the change you refer to, yes, it's pretty obvious it could be simplified, rather than covering four bugs in one changeset. Most of those changes are a result of the JDK-8182299 part of the change, which turns on parentheses. From the bug description, that was deliberate: "Since compiler warnings can detect real bugs, they should be enabled to the extent possible and the source code changed as needed". On the other hand, although that's a lengthy patch, there is little that's onerous or controversial in there. It would need careful review (there's at least one follow-on [0]), but it looks to me like most of it is things like bad types, missing default cases & parentheses, 90%+ of which would benefit other platforms too and no doubt be encountered by compilers there too. Also, Paul Hohensee, the author of this change, is active in 8u and so could perhaps comment on the viability of backporting this. The problem with starting to cherry-pick something like that is you then make the task of anyone backporting that later even harder. Incidentally, note that the changes is from OpenJDK 10, so it actually already has separate JDK and HotSpot changesets [1] [2] Which version of Clang are you testing with? > > Regards, > > -Simon > >> >> I'm not sure of the relevance of rampdown to this. This wouldn't be >> something approved for 8u252 at this stage.? 8u-dev will be available >> for commits again as soon as the bug system is switched over & JFR is >> merged. > Yes, you're right.? It is irrelevant. >> >> [0] https://bugs.openjdk.java.net/browse/JDK-8019470 >> >> Thanks, > [0] https://bugs.openjdk.java.net/browse/JDK-8184042 [1] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/228f0dc4d21a [2] http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/c044f8d03932 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Fri Feb 28 19:45:11 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 28 Feb 2020 16:45:11 -0300 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <3e49958c-f1dc-036d-0edf-e4218dee0cbd@redhat.com> Message-ID: <560d6c0a-1b02-9ae6-65dc-ccc7cd740cf5@redhat.com> Hi Andrew, Thanks for your feedback. Webrev.01: http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/ On 11/28/19 2:16 AM, Andrew John Hughes wrote: > > * The home of legal notices in 8u is the THIRD_PARTY_README file in each > repository, so the changes should go there, not simply be dropped. This > one actually seems to be missing at present (it suddenly appears with > JDK-8169925), so even more reason to add it above the section for the > PKCS#11 wrapper. License for PKCS #11 Cryptographic Token Interface v2.20 was never included in THIRD_PARTY_README but we can include license for v2.40 directly, taking parts of JDK-8169925 [1] and JDK-8238898 [2]. I've updated the commit message to reference these bugs. > * The original patch removes pkcs-11v2-20a3.h while the 8u backport doesn't. Good catch. Fixed. > * The change to TRAILER_FIELD_BC is correct, as altering > PSSParameterSpec would alter the Java 8 API. However, it may be worth > waiting for JDK-8146293, which has now been proposed for backport via > JDK-8230978, which will also initiate a spec change via the reference > implementation, jdk8u41. Change reverted to use PSSParameterSpec.TRAILER_FIELD_BC now that 8230978 (8146293) has been integrated. > * I'm seeing a lot of noise when comparing the 8u and 11u patches for > CK_RSA_PKCS_PSS_PARAMS.java, PKCS11Constants.java, p11_convert.c, > p11_digest.c, p11_sign.c & pkcs11t.h, though the changes look the same. > Have you checked that the patched files in 8u compare to those in 8u as > expected? I don't know why so much noise given that changes for PKCS11Constants.java, p11_convert.c, p11_digest.c, p11_sign.c and pkcs11t.h applied cleanly. It's not the first time I see noise in p11_* files though (I've seen the same in other backports). > * Please don't alter the SigInteropPSS.java test without comments > explaining why. As JDK-8146293 is imminent, I'd say just leave this as > it is and it will be automatically resolved. Now that JDK-8146293 has been backported, reverted the "Signature sigSunRsaSign = Signature.getInstance("RSASSA-PSS", "SunRsaSign");" change to use the original from the 11u backport. > * Why is the args argument dropped from the tests? Is this another > missing fix? > The reason is that 8144539 is not in 8u. I did not consider it a dependency as it's not directly related to the upgrade to PKCS#11 v2.40. Testing: * No regressions found in sun/security/pkcs11. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8169925 [2] - https://bugs.openjdk.java.net/browse/JDK-8238898 [3] - https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ece6722932ca [4] - https://bugs.openjdk.java.net/browse/JDK-8144539 From denghui.ddh at alibaba-inc.com Sat Feb 29 02:12:07 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 29 Feb 2020 10:12:07 +0800 Subject: =?UTF-8?B?UmU6IFtKRlJdIG5ldyBwYXRjaCBidW5kbGUgcHVibGlzaGVk?= In-Reply-To: References: <52BD543F-0385-40A5-A797-F19C907F8D9F@amazon.com> <1ad8343f-64f3-4d87-9a5d-dac83d0545d5.denghui.ddh@alibaba-inc.com> , Message-ID: Hi Mario, In JDK11, we can use 'make build-test-jdk-jtreg-native' to generate the native libs used by tests, but the make system of JDK8 doesn't have this ability. I think we can write a shell to wrapper all test action for TestNative.java like other similar test cases, such as JAWT.sh. And I can prepare the fix patch if you think it's an appropriate way. Thanks, Denghui Dong ------------------------------------------------------------------ From:Mario Torre Send Time:2020?2?28?(???) 20:29 To:???(??) Cc:jdk8u-dev Subject:Re: [JFR] new patch bundle published On Fri, Feb 28, 2020 at 11:16 AM Mario Torre wrote: > > Thanks for testing! > > I'll backport JDK-8202142 once the patch has been integrated directly > into the jdk8u-dev. > > We need to look more closely at the TestNative.java to see what's up, > do you have a patch for that already? The JTreg should have all the > necessary detail for the native library to be compiled. To clarify, this fails for me in every version of the JDK, not just 8u+JFR. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898