From magnus.ihse.bursie at oracle.com Fri Nov 1 10:33:34 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Nov 2019 11:33:34 +0100 Subject: RFR: JDK-8233381 Update copyright year in build system files Message-ID: <3723f904-91b2-febc-68d8-ce139c406fcb@oracle.com> I noticed that the copyright year was not properly updated to 2019 in multiple make files that was indeed modified in 2019. Bug: https://bugs.openjdk.java.net/browse/JDK-8233381 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8233381-update-copyright-year-2019/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Nov 1 10:43:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Nov 2019 11:43:26 +0100 Subject: RFR: JDK-8233383 Various minor fixes Message-ID: <7c7d5795-be13-fcf3-8d3c-a60fc5ef4a2a@oracle.com> This is a collection of minor fixes, that I've been gathering whenever I detected something that I thought needed fixing, but that by itself seemed to small to be worth the effort of opening a JBS issue. Summary of changes: * Unify creation of html from markdown for all *.md files in doc. * Move GensrcModuleInfo.gmk to gensrc directory.* Remove extraneous chars in autoconf source file header * Update documentation for new generated build names * Use - and not / for Windows CLI options * Fix typos Bug: https://bugs.openjdk.java.net/browse/JDK-8233383 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8233383-various-minor-fixes/webrev.01 /Magnus From rahman.usta.88 at gmail.com Fri Nov 1 10:16:24 2019 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 1 Nov 2019 11:16:24 +0100 Subject: Building Project Loom Message-ID: Hi, I tried to build project loom with given instructions in Wiki page. However, the build exit with error. Here you find the logs https://gist.github.com/rahmanusta/db03a9e4a6963204e5688b6bae81a796, could you please help? (MacOS Catalina 10.15) Thank you -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From dmitry.markov at oracle.com Fri Nov 1 13:09:33 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 1 Nov 2019 13:09:33 +0000 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> Message-ID: <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> Hi Alexey, I have updated the fix. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ Thanks, Dmitry > On 31 Oct 2019, at 16:27, Alexey Ivanov wrote: > > Hi Dmitry, > > 437 ?by the operating system. ? > > I'd modify the following text a bit: > To run the test correctly, the default global key shortcut should be disabled. Follow the steps above, and then deselect "Turn keyboard access on or off" property which is responsible for `CTRL + F1` combination. > > Does it sound clearer? > I'd not use backticks on the "Turn keyboard access on or off" because it's not something user is typing, nor is it a piece of code. Is the word ?property? correct? Does ?shortcut? or ?option? fit better? > > I'd recommend adding quotes around the option to look for: > 448 in the right-side pane look for "Turn off Windows key hotkeys" and double click on it; > > Consider adding an empty line before this line > 450 Note: restart is required to make the settings take effect. > to make it a separate paragraph in HTML. > > > Regards, > Alexey > > On 31/10/2019 10:56, Dmitry Markov wrote: >> Hi Alexey, >> >> I have updated the fix based on your recommendation. The new version is located at: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.02/ >> Also please find my answers inline. >> >> Thanks, >> Dmitry >> >>> On 29 Oct 2019, at 19:29, Alexey Ivanov > wrote: >>> >>> Hi Dmitry, >>> >>> Shall we drop hyphen in the header: ?Client UI Tests?? >>> >>> I think there should be no definite article in this sentence: ?use -the- key sequences?. >>> >>> ??Turn off Windowss key hotkeys??, there's an extra ?s? in Windows. >>> >>> ?Note: restart is required to make the settings take effect.? >>> Just to confirm: is signing out and signing in not enough? >> According to Microsoft site: restart is required but I guess signing out/in should work too. Unfortunately I do not have Windows on hand to check it out. >> >>> >>> I'd use backticks for gpedit markup: ?Type `gpedit` in the Search?? >>> >>> >>> Does it make sense to move the example into macOS section? Then the steps to disable the shortcut can be reduced to the required option only. The steps themselves should not be listed as code, i.e. no backticks. >>> >>> (For my understanding, "Turn keyboard access on or off" turns off only one specific shortcut, i.e. Ctrl+F1?) >> Yes, that?s right. I have added clarification to the doc. >> >>> >>> >>> Regards, >>> Alexey From erik.joelsson at oracle.com Fri Nov 1 13:41:37 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Nov 2019 06:41:37 -0700 Subject: Building Project Loom In-Reply-To: References: Message-ID: <4115e600-981c-c41f-f739-9302ffa66d4d@oracle.com> Hello Rahman, What version of Xcode are you using? The compile command line looks strange to me: /usr/local/opt/llvm at 4/bin/clang Is this your own build of clang? I'm not familiar with any special requirements needed for the loom project, but in general I would recommend establishing that you can build mainline jdk/jdk first. If mainline works, then check with the specific project if they have any recommendations particular to their work. /Erik On 2019-11-01 03:16, Rahman USTA wrote: > Hi, > > I tried to build project loom with given instructions in Wiki page. > However, the build exit with error. Here you find the logs > https://gist.github.com/rahmanusta/db03a9e4a6963204e5688b6bae81a796, could > you please help? (MacOS Catalina 10.15) > > Thank you > From erik.joelsson at oracle.com Fri Nov 1 13:42:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Nov 2019 06:42:33 -0700 Subject: RFR: JDK-8233381 Update copyright year in build system files In-Reply-To: <3723f904-91b2-febc-68d8-ce139c406fcb@oracle.com> References: <3723f904-91b2-febc-68d8-ce139c406fcb@oracle.com> Message-ID: <4aa3fcfe-03ed-3746-51a5-17686ba94de0@oracle.com> Looks good. /Erik On 2019-11-01 03:33, Magnus Ihse Bursie wrote: > I noticed that the copyright year was not properly updated to 2019 in > multiple make files that was indeed modified in 2019. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233381 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8233381-update-copyright-year-2019/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Nov 1 13:45:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Nov 2019 06:45:20 -0700 Subject: RFR: JDK-8233383 Various minor fixes In-Reply-To: <7c7d5795-be13-fcf3-8d3c-a60fc5ef4a2a@oracle.com> References: <7c7d5795-be13-fcf3-8d3c-a60fc5ef4a2a@oracle.com> Message-ID: Looks good. /Erik On 2019-11-01 03:43, Magnus Ihse Bursie wrote: > This is a collection of minor fixes, that I've been gathering whenever > I detected something that I thought needed fixing, but that by itself > seemed to small to be worth the effort of opening a JBS issue. > > Summary of changes: > * Unify creation of html from markdown for all *.md files in doc. > * Move GensrcModuleInfo.gmk to gensrc directory.* Remove extraneous > chars in autoconf source file header > * Update documentation for new generated build names > * Use - and not / for Windows CLI options > * Fix typos > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233383 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8233383-various-minor-fixes/webrev.01 > > /Magnus From lutz.schmidt at sap.com Fri Nov 1 14:10:41 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 1 Nov 2019 14:10:41 +0000 Subject: 8233078 : fix minimal VM build on Linux ppc64(le) Message-ID: <1D213519-CD1A-4623-8D62-66D58F841D8D@sap.com> Hi Matthias, your changes look good to me. Please note, however, that I'm not a Reviewer. One minor thing: do you really want to keep the old code (as comment) in sharedRuntime_ppc.cpp:2853? Thanks for putting this straight. Regards, Lutz ?On 29.10.19, 14:32, "hotspot-dev on behalf of Baesken, Matthias" wrote: Thanks . May I have a second review please ? Best regards, Matthias From: Doerr, Martin Sent: Dienstag, 29. Oktober 2019 13:48 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Cc: 'build-dev at openjdk.java.net' Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) Hi Matthias, > Not sure if there are any plans to support OptimizeFill on ppc64 ? This question is not related to this issue. Commenting out parts of it is not a good style. Thank you for your update. The new webrev looks good to me. Best regards, Martin From: Baesken, Matthias > Sent: Dienstag, 29. Oktober 2019 13:25 To: Doerr, Martin >; 'hotspot-dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) Hi Martin, thanks for the input . I did the adjustments you suggested; new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/ Regarding : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef COMPILER2 than commenting out." Currently the if (OptimizeFill) { ... } coding is dead on ppc . See : c2_globals.hpp ------------------------ 234 /* OptimizeFill not yet supported on PowerPC. */ \ 235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \ c2_init_ppc.cpp ------------------------ 53 if (OptimizeFill) { 54 warning("OptimizeFill is not supported on this CPU."); 55 FLAG_SET_DEFAULT(OptimizeFill, false); Not sure if there are any plans to support OptimizeFill on ppc64 ? Best regards, Matthias Hi Matthias, thanks for fixing it. I have a few requests: disassembler_ppc.cpp: Please remove includes completely if no longer needed (instead of commenting out). sharedRuntime_ppc.cpp: I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding code is not performance critical. stubGenerator_ppc.cpp: Code should better be protected by #ifdef COMPILER2 than commenting out. Otherwise, looks good to me. Thanks, Martin From: Baesken, Matthias > Sent: Dienstag, 29. Oktober 2019 12:42 To: 'hotspot-dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' >; Doerr, Martin > Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) Hello, please review the following fix . I recently experimented a bit with the minimal VM build on linux x86_64 (--with-jvm-features=minimal --with-jvm-variants=minimal) . This worked fine . However when I tried the minimal vm build on linux ppc64 / ppc64le , I noticed that it fails because of a few wrong dependencies . Thanks to Martin for the advice regarding Register ic = as_Register(Matcher::inline_cache_reg_encode()); Replacement with Register ic = R19_inline_cache_reg; In http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233078 http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/ Thanks, Matthias From alexey.ivanov at oracle.com Fri Nov 1 14:41:26 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 1 Nov 2019 14:41:26 +0000 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> Message-ID: <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> Thank you, Dmitry! The changes look good to me. On 01/11/2019 13:09, Dmitry Markov wrote: > Hi Alexey, > > I have updated the fix. Please find the new version here: > http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ > > Thanks, > Dmitry > >> On 31 Oct 2019, at 16:27, Alexey Ivanov > > wrote: >> >> Hi Dmitry, >> >> 437 ?by the operating system. ? >> >> I'd modify the following text a bit: >> To run the test correctly, the default global key shortcut should be >> disabled. Follow the steps above, and then deselect "Turn keyboard >> access on or off" property which is responsible for `CTRL + F1` >> combination. >> >> Does it sound clearer? >> I'd not use backticks on the "Turn keyboard access on or off" because >> it's not something user is typing, nor is it a piece of code. Is the >> word ?property? correct? Does ?shortcut? or ?option? fit better? >> >> I'd recommend adding quotes around the option to look for: >> 448 in the right-side pane look for "Turn off Windows key hotkeys" >> and double click on it; >> >> Consider adding an empty line before this line >> 450 Note: restart is required to make the settings take effect. >> to make it a separate paragraph in HTML. >> >> >> Regards, >> Alexey -- Regards, Alexey From rahman.usta.88 at gmail.com Fri Nov 1 18:22:38 2019 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 1 Nov 2019 19:22:38 +0100 Subject: Building Project Loom In-Reply-To: <4115e600-981c-c41f-f739-9302ffa66d4d@oracle.com> References: <4115e600-981c-c41f-f739-9302ffa66d4d@oracle.com> Message-ID: Hi Erik, Thanks for pointing that out to the right direction. I noticed that I have llvm package installed by homebrew. I uninstalled the package then built was successful. Thanks Rahman Erik Joelsson , 1 Kas 2019 Cum, 14:41 tarihinde ?unu yazd?: > Hello Rahman, > > What version of Xcode are you using? The compile command line looks > strange to me: > > /usr/local/opt/llvm at 4/bin/clang > > Is this your own build of clang? > > I'm not familiar with any special requirements needed for the loom > project, but in general I would recommend establishing that you can > build mainline jdk/jdk first. If mainline works, then check with the > specific project if they have any recommendations particular to their work. > > /Erik > > On 2019-11-01 03:16, Rahman USTA wrote: > > Hi, > > > > I tried to build project loom with given instructions in Wiki page. > > However, the build exit with error. Here you find the logs > > https://gist.github.com/rahmanusta/db03a9e4a6963204e5688b6bae81a796, > could > > you please help? (MacOS Catalina 10.15) > > > > Thank you > > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From Sergey.Bylokhov at oracle.com Fri Nov 1 20:58:55 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 Nov 2019 13:58:55 -0700 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> Message-ID: +1 On 11/1/19 7:41 am, Alexey Ivanov wrote: > Thank you, Dmitry! > The changes look good to me. > > On 01/11/2019 13:09, Dmitry Markov wrote: >> Hi Alexey, >> >> I have updated the fix. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >> >> Thanks, >> Dmitry >> >>> On 31 Oct 2019, at 16:27, Alexey Ivanov > wrote: >>> >>> Hi Dmitry, >>> >>> 437 ?by the operating system. ? >>> >>> I'd modify the following text a bit: >>> To run the test correctly, the default global key shortcut should be disabled. Follow the steps above, and then deselect "Turn keyboard access on or off" property which is responsible for `CTRL + F1` combination. >>> >>> Does it sound clearer? >>> I'd not use backticks on the "Turn keyboard access on or off" because it's not something user is typing, nor is it a piece of code. Is the word ?property? correct? Does ?shortcut? or ?option? fit better? >>> >>> I'd recommend adding quotes around the option to look for: >>> 448 in the right-side pane look for "Turn off Windows key hotkeys" and double click on it; >>> >>> Consider adding an empty line before this line >>> 450 Note: restart is required to make the settings take effect. >>> to make it a separate paragraph in HTML. >>> >>> >>> Regards, >>> Alexey -- Best regards, Sergey. From daniel.daugherty at oracle.com Sat Nov 2 12:43:10 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 2 Nov 2019 08:43:10 -0400 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> Message-ID: <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> Since this review contains build changes, I've added build-dev at ... Dan On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: > (Changed subject to review request) > > Hi, > > I converted LinuxDebuggerLocal.c to C++ code, and it works fine on > submit repo. > (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ > > Could you review it? > > > Thanks, > > Yasumasa > > > On 2019/11/01 8:54, Yasumasa Suenaga wrote: >> Hi David, >> >> On 2019/11/01 7:55, David Holmes wrote: >>> Hi Yasumasa, >>> >>> New build dependencies cannot be added lightly. This impacts >>> everyone who maintains build/test farms. >> >> Ok, thanks for telling it. >> >>> We already use the C++ demangling capabilities in the VM. Is there >>> some way to export that for use by libsaproc ? >>> >>> Otherwise using C++ demangle may still be the better choice given we >>> already have it as a dependency. >> >> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at >> decoder_linux.cpp . >> It is similar with my original proposal. >> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >> >> I agree with David to use C++ demangle way. >> However we need to choice the fix from following: >> >> ?? A. Convert LinuxDebuggerLocal.c to C++ code >> ?? B. Add C++ code for libsaproc.so to demangle symbols. >> >> I've discussed with Chris about it in [1]. >> Option A might be large change. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >> >> >>> David >>> >>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>> Hi Yasumasa, >>>> >>>> Here's the failure during configure: >>>> >>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>> demangle.h! You might be able to fix this by running 'sudo yum >>>> install binutils-devel'. >>>> >>>> Chris >>>> >>>> >>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>> Hi, >>>>> >>>>> I filed this enhancement to JBS: >>>>> >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>> >>>>> Also I pushed the changes to submit repo, but it was failed. >>>>> >>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>> >>>>> According to the email from Mach 5, dependency errors were >>>>> occurred in jib. >>>>> Can someone share the details? >>>>> I'm not familiar in jib, so I want help. >>>>> >>>>> ? mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>> You can change the configure script. I don't know if there's any >>>>>> concerns with using libiberty.a. That's possibly a legal question >>>>>> (GNU GPL). You might want to ask that on jdk-dev and/or build-dev. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> Thanks for quick reply! >>>>>>> >>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>> convert a lot of JNI calls to C++ style. >>>>>>> For example: >>>>>>> >>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>> ????? to >>>>>>> ? env->FindClass("java/lang/String") >>>>>>> >>>>>>> Can it be accepted? >>>>>>> >>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>> link libiberty.a which is provided by binutils. Thus I think we >>>>>>> need to check libiberty.a in configure script. Is it ok? >>>>>>> >>>>>>> >>>>>>> I prefer to use cplus_demangle() if we can change configure script. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>> order to do so you've put the new native code in its own file >>>>>>>> rather than in LinuxDebuggerLocal.c. I'd like to see that >>>>>>>> resolved. So either convert LinuxDebuggerLocal.c to C++, or use >>>>>>>> cplus_demangle(). >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>> mangled as below: >>>>>>>>> >>>>>>>>> >>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>> + 0x6ac >>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>> + 0x33d >>>>>>>>> >>>>>>>>> >>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>> I think we can demangle in jstack with this patch. If it is >>>>>>>>> accepted, I will file it to JBS and send review request. >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>> >>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>> >>>>>>>>> >>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, Klass*, >>>>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>> >>>>>>>>> >>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch adds >>>>>>>>> C++ source to SA. >>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>> But this function is provided by libiberty.a, so we need to >>>>>>>>> link it to libsaproc and need to check libiberty.a in >>>>>>>>> configure script. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> > From jonathan.gibbons at oracle.com Sun Nov 3 14:51:54 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 3 Nov 2019 06:51:54 -0800 Subject: RFR (XXS) 8233422 : Extra space in the title of the HTML javadoc page In-Reply-To: References: Message-ID: <08826037-3248-7905-1012-440559c2817b@oracle.com> Forwarding to build-dev. build-folk, This one's for you. -- Jon On 11/1/19 4:24 PM, Ivan Gerasimov wrote: > Hello! > > Every javadoc HTML page has a title, which includes the product and > the version information. > > For example, for the page [1] it is "String (Java 13 SE & JDK 13 )" > > [1] > https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/String.html > > Note the extra space before the closing parenthesis. > > Would you please help review a trivial fix, which removes this extra > space? > > (The space will still be preserved if the build information needs to > be included.) > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233422 > WEBREV: http://cr.openjdk.java.net/~igerasim/8233422/00/webrev/ > From dmitry.markov at oracle.com Sun Nov 3 15:38:09 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sun, 3 Nov 2019 15:38:09 +0000 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> Message-ID: <8D120F09-7097-47DC-87BE-4C14C9796821@oracle.com> Alexey and Sergey, thank you for the approval! I wonder whether it is enough or I need one more ?+1? from build-folk. Thanks, Dmitry > On 1 Nov 2019, at 20:58, Sergey Bylokhov wrote: > > +1 > > On 11/1/19 7:41 am, Alexey Ivanov wrote: >> Thank you, Dmitry! >> The changes look good to me. >> On 01/11/2019 13:09, Dmitry Markov wrote: >>> Hi Alexey, >>> >>> I have updated the fix. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >>> >>> Thanks, >>> Dmitry >>> >>>> On 31 Oct 2019, at 16:27, Alexey Ivanov > wrote: >>>> >>>> Hi Dmitry, >>>> >>>> 437 ?by the operating system. ? >>>> >>>> I'd modify the following text a bit: >>>> To run the test correctly, the default global key shortcut should be disabled. Follow the steps above, and then deselect "Turn keyboard access on or off" property which is responsible for `CTRL + F1` combination. >>>> >>>> Does it sound clearer? >>>> I'd not use backticks on the "Turn keyboard access on or off" because it's not something user is typing, nor is it a piece of code. Is the word ?property? correct? Does ?shortcut? or ?option? fit better? >>>> >>>> I'd recommend adding quotes around the option to look for: >>>> 448 in the right-side pane look for "Turn off Windows key hotkeys" and double click on it; >>>> >>>> Consider adding an empty line before this line >>>> 450 Note: restart is required to make the settings take effect. >>>> to make it a separate paragraph in HTML. >>>> >>>> >>>> Regards, >>>> Alexey > > > -- > Best regards, Sergey. From matthias.baesken at sap.com Mon Nov 4 08:48:55 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 4 Nov 2019 08:48:55 +0000 Subject: 8233078 : fix minimal VM build on Linux ppc64(le) In-Reply-To: <1D213519-CD1A-4623-8D62-66D58F841D8D@sap.com> References: <1D213519-CD1A-4623-8D62-66D58F841D8D@sap.com> Message-ID: Thanks for the reviews ! > One minor thing: do you really want to keep the old code (as comment) in > sharedRuntime_ppc.cpp:2853? I remove it . Best regards, Matthias > -----Original Message----- > From: Schmidt, Lutz > Sent: Freitag, 1. November 2019 15:11 > To: Baesken, Matthias ; Doerr, Martin > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: 'build-dev at openjdk.java.net' > Subject: Re: 8233078 : fix minimal VM build on Linux ppc64(le) > > Hi Matthias, > > your changes look good to me. Please note, however, that I'm not a > Reviewer. > > One minor thing: do you really want to keep the old code (as comment) in > sharedRuntime_ppc.cpp:2853? > > Thanks for putting this straight. > > Regards, > Lutz > > ?On 29.10.19, 14:32, "hotspot-dev on behalf of Baesken, Matthias" dev-bounces at openjdk.java.net on behalf of matthias.baesken at sap.com> > wrote: > > Thanks . > May I have a second review please ? > > Best regards, Matthias > > From: Doerr, Martin > Sent: Dienstag, 29. Oktober 2019 13:48 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) > > Hi Matthias, > > > Not sure if there are any plans to support OptimizeFill on ppc64 ? > This question is not related to this issue. > Commenting out parts of it is not a good style. > > Thank you for your update. The new webrev looks good to me. > > Best regards, > Martin > > > From: Baesken, Matthias > > > Sent: Dienstag, 29. Oktober 2019 13:25 > To: Doerr, Martin > >; 'hotspot- > dev at openjdk.java.net' dev at openjdk.java.net>> > Cc: 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) > > Hi Martin, thanks for the input . > I did the adjustments you suggested; new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/ > > Regarding : stubGenerator_ppc.cpp: "Code should better be protected by > #ifdef COMPILER2 than commenting out." > Currently the if (OptimizeFill) { ... } coding is dead on ppc . > > See : > c2_globals.hpp > ------------------------ > 234 /* OptimizeFill not yet supported on PowerPC. */ \ > 235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \ > > c2_init_ppc.cpp > ------------------------ > 53 if (OptimizeFill) { > 54 warning("OptimizeFill is not supported on this CPU."); > 55 FLAG_SET_DEFAULT(OptimizeFill, false); > > > Not sure if there are any plans to support OptimizeFill on ppc64 ? > > Best regards, Matthias > > > > > Hi Matthias, > > thanks for fixing it. I have a few requests: > > disassembler_ppc.cpp: > Please remove includes completely if no longer needed (instead of > commenting out). > > sharedRuntime_ppc.cpp: > I think it's better to remove the 2 align(InteriorEntryAlignment). > Succeeding code is not performance critical. > > stubGenerator_ppc.cpp: > Code should better be protected by #ifdef COMPILER2 than commenting > out. > > Otherwise, looks good to me. > > Thanks, > Martin > > > From: Baesken, Matthias > > > Sent: Dienstag, 29. Oktober 2019 12:42 > To: 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: 'build-dev at openjdk.java.net' dev at openjdk.java.net>; Doerr, > Martin > > Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) > > Hello, please review the following fix . > I recently experimented a bit with the minimal VM build on linux x86_64 > (--with-jvm-features=minimal --with-jvm-variants=minimal) . > This worked fine . > > However when I tried the minimal vm build on linux ppc64 / ppc64le , I > noticed that it fails because of a few wrong dependencies . > Thanks to Martin for the advice regarding > > Register ic = as_Register(Matcher::inline_cache_reg_encode()); > > Replacement with > > > Register ic = R19_inline_cache_reg; > > In > http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu > /ppc/sharedRuntime_ppc.cpp.frames.html > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8233078 > http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/ > > > Thanks, Matthias > > > > From magnus.ihse.bursie at oracle.com Mon Nov 4 10:20:59 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Nov 2019 11:20:59 +0100 Subject: RFR (XXS) 8233422 : Extra space in the title of the HTML javadoc page In-Reply-To: <08826037-3248-7905-1012-440559c2817b@oracle.com> References: <08826037-3248-7905-1012-440559c2817b@oracle.com> Message-ID: On 2019-11-03 15:51, Jonathan Gibbons wrote: > Forwarding to build-dev. > > build-folk, > > This one's for you. > > -- Jon > > On 11/1/19 4:24 PM, Ivan Gerasimov wrote: >> Hello! >> >> Every javadoc HTML page has a title, which includes the product and >> the version information. >> >> For example, for the page [1] it is "String (Java 13 SE & JDK 13 )" >> >> [1] >> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/String.html >> >> Note the extra space before the closing parenthesis. >> >> Would you please help review a trivial fix, which removes this extra >> space? >> >> (The space will still be preserved if the build information needs to >> be included.) >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233422 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8233422/00/webrev/ Good catch! However, there's an idiomatic way to achieve this in our makefiles, without introducing a new $(EMPTY_STRING). Instead of: DRAFT_MARKER_TITLE := $(EMPTY_STRING) [ad-hoc build] do this: DRAFT_MARKER_TITLE := $(SPACE)[ad-hoc build] /Magnus From magnus.ihse.bursie at oracle.com Mon Nov 4 10:24:57 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Nov 2019 11:24:57 +0100 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <8D120F09-7097-47DC-87BE-4C14C9796821@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> <8D120F09-7097-47DC-87BE-4C14C9796821@oracle.com> Message-ID: <85b9336b-a0f8-0dbd-14f2-d692a30bf695@oracle.com> On 2019-11-03 16:38, Dmitry Markov wrote: > Alexey and Sergey, thank you for the approval! > I wonder whether it is enough or I need one more ?+1? from build-folk. You really don't need it, but here you get one. :-) I think it was good that you continued polish the addition. The latest version looks much better than the original suggestion! /Magnus > > Thanks, > Dmitry > >> On 1 Nov 2019, at 20:58, Sergey Bylokhov > > wrote: >> >> +1 >> >> On 11/1/19 7:41 am, Alexey Ivanov wrote: >>> Thank you, Dmitry! >>> The changes look good to me. >>> On 01/11/2019 13:09, Dmitry Markov wrote: >>>> Hi Alexey, >>>> >>>> I have updated the fix. Please find the new version here: >>>> http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >>>> >>>> Thanks, >>>> Dmitry >>>> >>>>> On 31 Oct 2019, at 16:27, Alexey Ivanov >>>> >>>>> > wrote: >>>>> >>>>> Hi Dmitry, >>>>> >>>>> 437 ?by the operating system. ? >>>>> >>>>> I'd modify the following text a bit: >>>>> To run the test correctly, the default global key shortcut should >>>>> be disabled. Follow the steps above, and then deselect "Turn >>>>> keyboard access on or off" property which is responsible for `CTRL >>>>> + F1` combination. >>>>> >>>>> Does it sound clearer? >>>>> I'd not use backticks on the "Turn keyboard access on or off" >>>>> because it's not something user is typing, nor is it a piece of >>>>> code. Is the word ?property? correct? Does ?shortcut? or ?option? >>>>> fit better? >>>>> >>>>> I'd recommend adding quotes around the option to look for: >>>>> 448 in the right-side pane look for "Turn off Windows key hotkeys" >>>>> and double click on it; >>>>> >>>>> Consider adding an empty line before this line >>>>> 450 Note: restart is required to make the settings take effect. >>>>> to make it a separate paragraph in HTML. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >> >> >> -- >> Best regards, Sergey. > From magnus.ihse.bursie at oracle.com Mon Nov 4 10:27:44 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Nov 2019 11:27:44 +0100 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> Message-ID: On 2019-11-02 13:43, Daniel D. Daugherty wrote: > Since this review contains build changes, I've added build-dev at ... Thanks Dan for noticing this and cc:ing us. Yasumasa: build changes look fine. Thanks. /Magnus > > Dan > > > On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >> (Changed subject to review request) >> >> Hi, >> >> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on >> submit repo. >> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> On 2019/11/01 7:55, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> New build dependencies cannot be added lightly. This impacts >>>> everyone who maintains build/test farms. >>> >>> Ok, thanks for telling it. >>> >>>> We already use the C++ demangling capabilities in the VM. Is there >>>> some way to export that for use by libsaproc ? >>>> >>>> Otherwise using C++ demangle may still be the better choice given >>>> we already have it as a dependency. >>> >>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at >>> decoder_linux.cpp . >>> It is similar with my original proposal. >>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>> >>> I agree with David to use C++ demangle way. >>> However we need to choice the fix from following: >>> >>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>> >>> I've discussed with Chris about it in [1]. >>> Option A might be large change. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>> >>> >>>> David >>>> >>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Here's the failure during configure: >>>>> >>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>> install binutils-devel'. >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>> Hi, >>>>>> >>>>>> I filed this enhancement to JBS: >>>>>> >>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>> >>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>> >>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>> >>>>>> According to the email from Mach 5, dependency errors were >>>>>> occurred in jib. >>>>>> Can someone share the details? >>>>>> I'm not familiar in jib, so I want help. >>>>>> >>>>>> ? mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>> You can change the configure script. I don't know if there's any >>>>>>> concerns with using libiberty.a. That's possibly a legal >>>>>>> question (GNU GPL). You might want to ask that on jdk-dev and/or >>>>>>> build-dev. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> Thanks for quick reply! >>>>>>>> >>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>> For example: >>>>>>>> >>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>> ????? to >>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>> >>>>>>>> Can it be accepted? >>>>>>>> >>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>>> link libiberty.a which is provided by binutils. Thus I think we >>>>>>>> need to check libiberty.a in configure script. Is it ok? >>>>>>>> >>>>>>>> >>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>> script. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>> order to do so you've put the new native code in its own file >>>>>>>>> rather than in LinuxDebuggerLocal.c. I'd like to see that >>>>>>>>> resolved. So either convert LinuxDebuggerLocal.c to C++, or >>>>>>>>> use cplus_demangle(). >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>> mangled as below: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>> + 0x6ac >>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>> + 0x33d >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>> I think we can demangle in jstack with this patch. If it is >>>>>>>>>> accepted, I will file it to JBS and send review request. >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>> >>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>> adds C++ source to SA. >>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>> But this function is provided by libiberty.a, so we need to >>>>>>>>>> link it to libsaproc and need to check libiberty.a in >>>>>>>>>> configure script. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >> > From dmitry.markov at oracle.com Mon Nov 4 10:55:09 2019 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 4 Nov 2019 10:55:09 +0000 Subject: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests In-Reply-To: <85b9336b-a0f8-0dbd-14f2-d692a30bf695@oracle.com> References: <5096E196-8A4F-4A6A-A419-F9FFF7D59A0D@oracle.com> <8f9d6d2e-4002-df17-119f-4f52127393bc@oracle.com> <1439841D-22B8-49A9-9385-235EC9B81C72@oracle.com> <8a01b08a-051a-d808-7882-d9edad825fed@oracle.com> <3776f84b-b845-3233-47da-021aba45ff84@oracle.com> <9D58F2E4-898A-4231-B7A5-E9CCF106243F@oracle.com> <6ee471b3-2029-e764-f327-b231d073f491@oracle.com> <8D120F09-7097-47DC-87BE-4C14C9796821@oracle.com> <85b9336b-a0f8-0dbd-14f2-d692a30bf695@oracle.com> Message-ID: <9F2ECB52-254C-4506-8169-947248AE8AD9@oracle.com> Thank you, Magnus! Dmitry > On 4 Nov 2019, at 10:24, Magnus Ihse Bursie wrote: > > > > On 2019-11-03 16:38, Dmitry Markov wrote: >> Alexey and Sergey, thank you for the approval! >> I wonder whether it is enough or I need one more ?+1? from build-folk. > You really don't need it, but here you get one. :-) > > I think it was good that you continued polish the addition. The latest version looks much better than the original suggestion! > > /Magnus >> >> Thanks, >> Dmitry >> >>> On 1 Nov 2019, at 20:58, Sergey Bylokhov > wrote: >>> >>> +1 >>> >>> On 11/1/19 7:41 am, Alexey Ivanov wrote: >>>> Thank you, Dmitry! >>>> The changes look good to me. >>>> On 01/11/2019 13:09, Dmitry Markov wrote: >>>>> Hi Alexey, >>>>> >>>>> I have updated the fix. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>>> On 31 Oct 2019, at 16:27, Alexey Ivanov >> wrote: >>>>>> >>>>>> Hi Dmitry, >>>>>> >>>>>> 437 ?by the operating system. ? >>>>>> >>>>>> I'd modify the following text a bit: >>>>>> To run the test correctly, the default global key shortcut should be disabled. Follow the steps above, and then deselect "Turn keyboard access on or off" property which is responsible for `CTRL + F1` combination. >>>>>> >>>>>> Does it sound clearer? >>>>>> I'd not use backticks on the "Turn keyboard access on or off" because it's not something user is typing, nor is it a piece of code. Is the word ?property? correct? Does ?shortcut? or ?option? fit better? >>>>>> >>>>>> I'd recommend adding quotes around the option to look for: >>>>>> 448 in the right-side pane look for "Turn off Windows key hotkeys" and double click on it; >>>>>> >>>>>> Consider adding an empty line before this line >>>>>> 450 Note: restart is required to make the settings take effect. >>>>>> to make it a separate paragraph in HTML. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>> >>> >>> -- >>> Best regards, Sergey. >> > From suenaga at oss.nttdata.com Mon Nov 4 13:09:28 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 4 Nov 2019 22:09:28 +0900 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> Message-ID: <297ac028-5e4b-1bff-789f-0a47035fdaeb@oss.nttdata.com> Thanks Magnus and Dan! I will push it. Yasumasa On 2019/11/04 19:27, Magnus Ihse Bursie wrote: > On 2019-11-02 13:43, Daniel D. Daugherty wrote: >> Since this review contains build changes, I've added build-dev at ... > Thanks Dan for noticing this and cc:ing us. > > Yasumasa: build changes look fine. Thanks. > > /Magnus >> >> Dan >> >> >> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>> (Changed subject to review request) >>> >>> Hi, >>> >>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on submit repo. >>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2019/11/01 7:55, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> New build dependencies cannot be added lightly. This impacts everyone who maintains build/test farms. >>>> >>>> Ok, thanks for telling it. >>>> >>>>> We already use the C++ demangling capabilities in the VM. Is there some way to export that for use by libsaproc ? >>>>> >>>>> Otherwise using C++ demangle may still be the better choice given we already have it as a dependency. >>>> >>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at decoder_linux.cpp . >>>> It is similar with my original proposal. >>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>> >>>> I agree with David to use C++ demangle way. >>>> However we need to choice the fix from following: >>>> >>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>> >>>> I've discussed with Chris about it in [1]. >>>> Option A might be large change. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>> >>>> >>>>> David >>>>> >>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Here's the failure during configure: >>>>>> >>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find demangle.h! You might be able to fix this by running 'sudo yum install binutils-devel'. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I filed this enhancement to JBS: >>>>>>> >>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>> >>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>> >>>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>> >>>>>>> According to the email from Mach 5, dependency errors were occurred in jib. >>>>>>> Can someone share the details? >>>>>>> I'm not familiar in jib, so I want help. >>>>>>> >>>>>>> ? mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>> You can change the configure script. I don't know if there's any concerns with using libiberty.a. That's possibly a legal question (GNU GPL). You might want to ask that on jdk-dev and/or build-dev. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> Thanks for quick reply! >>>>>>>>> >>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to convert a lot of JNI calls to C++ style. >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>> ????? to >>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>> >>>>>>>>> Can it be accepted? >>>>>>>>> >>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to link libiberty.a which is provided by binutils. Thus I think we need to check libiberty.a in configure script. Is it ok? >>>>>>>>> >>>>>>>>> >>>>>>>>> I prefer to use cplus_demangle() if we can change configure script. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> I don't have concerns with adding C++ source to SA, but in order to do so you've put the new native code in its own file rather than in LinuxDebuggerLocal.c. I'd like to see that resolved. So either convert LinuxDebuggerLocal.c to C++, or use cplus_demangle(). >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were mangled as below: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0x00007ff255a8fa4c _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x6ac >>>>>>>>>>> 0x00007ff255a8cc1d _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread + 0x33d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We can demangle them via c++filt, but I think it is more convenience if jstack can show demangling symbols. >>>>>>>>>>> I think we can demangle in jstack with this patch. If it is accepted, I will file it to JBS and send review request. >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>> >>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch adds C++ source to SA. >>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>> But this function is provided by libiberty.a, so we need to link it to libsaproc and need to check libiberty.a in configure script. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>> >> > From ivan.gerasimov at oracle.com Mon Nov 4 20:21:56 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 4 Nov 2019 12:21:56 -0800 Subject: RFR (XXS) 8233422 : Extra space in the title of the HTML javadoc page In-Reply-To: References: <08826037-3248-7905-1012-440559c2817b@oracle.com> Message-ID: Thank you Magnus for your suggestion! Please see the webrev updated accordingly: http://cr.openjdk.java.net/~igerasim/8233422/01/webrev/ With kind regards, Ivan On 11/4/19 2:20 AM, Magnus Ihse Bursie wrote: > > > On 2019-11-03 15:51, Jonathan Gibbons wrote: >> Forwarding to build-dev. >> >> build-folk, >> >> This one's for you. >> >> -- Jon >> >> On 11/1/19 4:24 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Every javadoc HTML page has a title, which includes the product and >>> the version information. >>> >>> For example, for the page [1] it is "String (Java 13 SE & JDK 13 )" >>> >>> [1] >>> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/String.html >>> >>> Note the extra space before the closing parenthesis. >>> >>> Would you please help review a trivial fix, which removes this extra >>> space? >>> >>> (The space will still be preserved if the build information needs to >>> be included.) >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233422 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8233422/00/webrev/ > Good catch! However, there's an idiomatic way to achieve this in our > makefiles, without introducing a new $(EMPTY_STRING). > > Instead of: > > DRAFT_MARKER_TITLE := $(EMPTY_STRING) [ad-hoc build] > > do this: > > DRAFT_MARKER_TITLE := $(SPACE)[ad-hoc build] > > /Magnus > > > -- With kind regards, Ivan Gerasimov From erik.joelsson at oracle.com Mon Nov 4 20:46:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Nov 2019 12:46:04 -0800 Subject: RFR (XXS) 8233422 : Extra space in the title of the HTML javadoc page In-Reply-To: References: <08826037-3248-7905-1012-440559c2817b@oracle.com> Message-ID: <8657af5a-6ad6-972d-9640-c7c3ae21ad3e@oracle.com> Looks good. /Erik On 2019-11-04 12:21, Ivan Gerasimov wrote: > Thank you Magnus for your suggestion! > > Please see the webrev updated accordingly: > > http://cr.openjdk.java.net/~igerasim/8233422/01/webrev/ > > With kind regards, > > Ivan > > > On 11/4/19 2:20 AM, Magnus Ihse Bursie wrote: >> >> >> On 2019-11-03 15:51, Jonathan Gibbons wrote: >>> Forwarding to build-dev. >>> >>> build-folk, >>> >>> This one's for you. >>> >>> -- Jon >>> >>> On 11/1/19 4:24 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Every javadoc HTML page has a title, which includes the product and >>>> the version information. >>>> >>>> For example, for the page [1] it is "String (Java 13 SE & JDK 13 )" >>>> >>>> [1] >>>> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/String.html >>>> >>>> Note the extra space before the closing parenthesis. >>>> >>>> Would you please help review a trivial fix, which removes this >>>> extra space? >>>> >>>> (The space will still be preserved if the build information needs >>>> to be included.) >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233422 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8233422/00/webrev/ >> Good catch! However, there's an idiomatic way to achieve this in our >> makefiles, without introducing a new $(EMPTY_STRING). >> >> Instead of: >> >> DRAFT_MARKER_TITLE := $(EMPTY_STRING) [ad-hoc build] >> >> do this: >> >> DRAFT_MARKER_TITLE := $(SPACE)[ad-hoc build] >> >> /Magnus >> >> >> From magnus.ihse.bursie at oracle.com Mon Nov 4 21:29:05 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Nov 2019 22:29:05 +0100 Subject: RFR (XXS) 8233422 : Extra space in the title of the HTML javadoc page In-Reply-To: References: <08826037-3248-7905-1012-440559c2817b@oracle.com> Message-ID: <54375DA3-6FEB-4A99-8797-915409EEB59F@oracle.com> Looks good now. /Magnus > 4 nov. 2019 kl. 21:21 skrev Ivan Gerasimov : > > Thank you Magnus for your suggestion! > > Please see the webrev updated accordingly: > > http://cr.openjdk.java.net/~igerasim/8233422/01/webrev/ > > With kind regards, > > Ivan > > >> On 11/4/19 2:20 AM, Magnus Ihse Bursie wrote: >> >> >>> On 2019-11-03 15:51, Jonathan Gibbons wrote: >>> Forwarding to build-dev. >>> >>> build-folk, >>> >>> This one's for you. >>> >>> -- Jon >>> >>>> On 11/1/19 4:24 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> Every javadoc HTML page has a title, which includes the product and the version information. >>>> >>>> For example, for the page [1] it is "String (Java 13 SE & JDK 13 )" >>>> >>>> [1] https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/String.html >>>> >>>> Note the extra space before the closing parenthesis. >>>> >>>> Would you please help review a trivial fix, which removes this extra space? >>>> >>>> (The space will still be preserved if the build information needs to be included.) >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233422 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8233422/00/webrev/ >> Good catch! However, there's an idiomatic way to achieve this in our makefiles, without introducing a new $(EMPTY_STRING). >> >> Instead of: >> >> DRAFT_MARKER_TITLE := $(EMPTY_STRING) [ad-hoc build] >> >> do this: >> >> DRAFT_MARKER_TITLE := $(SPACE)[ad-hoc build] >> >> /Magnus >> >> >> > -- > With kind regards, > Ivan Gerasimov > From david.holmes at oracle.com Wed Nov 6 13:13:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Nov 2019 23:13:57 +1000 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> Message-ID: <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: > On 2019-11-02 13:43, Daniel D. Daugherty wrote: >> Since this review contains build changes, I've added build-dev at ... > Thanks Dan for noticing this and cc:ing us. > > Yasumasa: build changes look fine. Thanks. This change broke all cross-compilation. David > /Magnus >> >> Dan >> >> >> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>> (Changed subject to review request) >>> >>> Hi, >>> >>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on >>> submit repo. >>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2019/11/01 7:55, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> New build dependencies cannot be added lightly. This impacts >>>>> everyone who maintains build/test farms. >>>> >>>> Ok, thanks for telling it. >>>> >>>>> We already use the C++ demangling capabilities in the VM. Is there >>>>> some way to export that for use by libsaproc ? >>>>> >>>>> Otherwise using C++ demangle may still be the better choice given >>>>> we already have it as a dependency. >>>> >>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at >>>> decoder_linux.cpp . >>>> It is similar with my original proposal. >>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>> >>>> I agree with David to use C++ demangle way. >>>> However we need to choice the fix from following: >>>> >>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>> >>>> I've discussed with Chris about it in [1]. >>>> Option A might be large change. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>> >>>> >>>> >>>>> David >>>>> >>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Here's the failure during configure: >>>>>> >>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>> install binutils-devel'. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I filed this enhancement to JBS: >>>>>>> >>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>> >>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>> >>>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>> ? http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>> >>>>>>> According to the email from Mach 5, dependency errors were >>>>>>> occurred in jib. >>>>>>> Can someone share the details? >>>>>>> I'm not familiar in jib, so I want help. >>>>>>> >>>>>>> ? mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>> You can change the configure script. I don't know if there's any >>>>>>>> concerns with using libiberty.a. That's possibly a legal >>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev and/or >>>>>>>> build-dev. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> Thanks for quick reply! >>>>>>>>> >>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>> ????? to >>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>> >>>>>>>>> Can it be accepted? >>>>>>>>> >>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>>>> link libiberty.a which is provided by binutils. Thus I think we >>>>>>>>> need to check libiberty.a in configure script. Is it ok? >>>>>>>>> >>>>>>>>> >>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>> script. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>> order to do so you've put the new native code in its own file >>>>>>>>>> rather than in LinuxDebuggerLocal.c. I'd like to see that >>>>>>>>>> resolved. So either convert LinuxDebuggerLocal.c to C++, or >>>>>>>>>> use cplus_demangle(). >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>> mangled as below: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>> + 0x6ac >>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>> + 0x33d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>> I think we can demangle in jstack with this patch. If it is >>>>>>>>>>> accepted, I will file it to JBS and send review request. >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>> >>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>> But this function is provided by libiberty.a, so we need to >>>>>>>>>>> link it to libsaproc and need to check libiberty.a in >>>>>>>>>>> configure script. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>> >> > From erik.joelsson at oracle.com Wed Nov 6 13:33:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 6 Nov 2019 05:33:17 -0800 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> Message-ID: <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> I looked closer at it now and the build change is not good. Any toolchain definition with BUILD in the name, like TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools that are run during the build. I believe the fix is to just remove the "BUILD_". /Erik On 2019-11-06 05:13, David Holmes wrote: > On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>> Since this review contains build changes, I've added build-dev at ... >> Thanks Dan for noticing this and cc:ing us. >> >> Yasumasa: build changes look fine. Thanks. > > This change broke all cross-compilation. > > David > >> /Magnus >>> >>> Dan >>> >>> >>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>> (Changed subject to review request) >>>> >>>> Hi, >>>> >>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on >>>> submit repo. >>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>> >>>> Could you review it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> New build dependencies cannot be added lightly. This impacts >>>>>> everyone who maintains build/test farms. >>>>> >>>>> Ok, thanks for telling it. >>>>> >>>>>> We already use the C++ demangling capabilities in the VM. Is >>>>>> there some way to export that for use by libsaproc ? >>>>>> >>>>>> Otherwise using C++ demangle may still be the better choice given >>>>>> we already have it as a dependency. >>>>> >>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at >>>>> decoder_linux.cpp . >>>>> It is similar with my original proposal. >>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>> >>>>> I agree with David to use C++ demangle way. >>>>> However we need to choice the fix from following: >>>>> >>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>> >>>>> I've discussed with Chris about it in [1]. >>>>> Option A might be large change. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>> >>>>> >>>>> >>>>>> David >>>>>> >>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Here's the failure during configure: >>>>>>> >>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>>> install binutils-devel'. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I filed this enhancement to JBS: >>>>>>>> >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>> >>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>> >>>>>>>> According to the email from Mach 5, dependency errors were >>>>>>>> occurred in jib. >>>>>>>> Can someone share the details? >>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>> >>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>> You can change the configure script. I don't know if there's >>>>>>>>> any concerns with using libiberty.a. That's possibly a legal >>>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev >>>>>>>>> and/or build-dev. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Chris, >>>>>>>>>> >>>>>>>>>> Thanks for quick reply! >>>>>>>>>> >>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>> ????? to >>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>> >>>>>>>>>> Can it be accepted? >>>>>>>>>> >>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>>>>> link libiberty.a which is provided by binutils. Thus I think >>>>>>>>>> we need to check libiberty.a in configure script. Is it ok? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>>> script. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>>> order to do so you've put the new native code in its own >>>>>>>>>>> file rather than in LinuxDebuggerLocal.c. I'd like to see >>>>>>>>>>> that resolved. So either convert LinuxDebuggerLocal.c to >>>>>>>>>>> C++, or use cplus_demangle(). >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>>> mangled as below: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>>> + 0x6ac >>>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>>> + 0x33d >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>>> I think we can demangle in jstack with this patch. If it is >>>>>>>>>>>> accepted, I will file it to JBS and send review request. >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>> >>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>> But this function is provided by libiberty.a, so we need to >>>>>>>>>>>> link it to libsaproc and need to check libiberty.a in >>>>>>>>>>>> configure script. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>> >>> >> From suenaga at oss.nttdata.com Wed Nov 6 13:50:34 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 6 Nov 2019 22:50:34 +0900 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> Message-ID: <832479a6-dbb5-00ed-5ef6-18a1b4b71151@oss.nttdata.com> Hi, Thanks for telling it me. I removed "BUILD_" from Makefile as Erik said, then it works fine on my Linux box: ``` diff -r a3b046720c3b make/lib/Lib-jdk.hotspot.agent.gmk --- a/make/lib/Lib-jdk.hotspot.agent.gmk Wed Nov 06 21:49:30 2019 +0900 +++ b/make/lib/Lib-jdk.hotspot.agent.gmk Wed Nov 06 22:48:00 2019 +0900 @@ -55,7 +55,7 @@ SA_TOOLCHAIN := $(TOOLCHAIN_DEFAULT) ifeq ($(call isTargetOs, linux), true) - SA_TOOLCHAIN := TOOLCHAIN_BUILD_LINK_CXX + SA_TOOLCHAIN := TOOLCHAIN_LINK_CXX endif ################################################################################ ``` Could you file it to JBS? I don't know details. If you assign it to me, I will send review request. Thanks, Yasumasa On 2019/11/06 22:33, Erik Joelsson wrote: > I looked closer at it now and the build change is not good. Any toolchain definition with BUILD in the name, like TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools that are run during the build. I believe the fix is to just remove the "BUILD_". > > /Erik > > On 2019-11-06 05:13, David Holmes wrote: >> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >>> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>>> Since this review contains build changes, I've added build-dev at ... >>> Thanks Dan for noticing this and cc:ing us. >>> >>> Yasumasa: build changes look fine. Thanks. >> >> This change broke all cross-compilation. >> >> David >> >>> /Magnus >>>> >>>> Dan >>>> >>>> >>>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>>> (Changed subject to review request) >>>>> >>>>> Hi, >>>>> >>>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on submit repo. >>>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>>> >>>>> Could you review it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> New build dependencies cannot be added lightly. This impacts everyone who maintains build/test farms. >>>>>> >>>>>> Ok, thanks for telling it. >>>>>> >>>>>>> We already use the C++ demangling capabilities in the VM. Is there some way to export that for use by libsaproc ? >>>>>>> >>>>>>> Otherwise using C++ demangle may still be the better choice given we already have it as a dependency. >>>>>> >>>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at decoder_linux.cpp . >>>>>> It is similar with my original proposal. >>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>> >>>>>> I agree with David to use C++ demangle way. >>>>>> However we need to choice the fix from following: >>>>>> >>>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>>> >>>>>> I've discussed with Chris about it in [1]. >>>>>> Option A might be large change. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Here's the failure during configure: >>>>>>>> >>>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find demangle.h! You might be able to fix this by running 'sudo yum install binutils-devel'. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I filed this enhancement to JBS: >>>>>>>>> >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>>> >>>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>>> >>>>>>>>> According to the email from Mach 5, dependency errors were occurred in jib. >>>>>>>>> Can someone share the details? >>>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>>> >>>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>>> You can change the configure script. I don't know if there's any concerns with using libiberty.a. That's possibly a legal question (GNU GPL). You might want to ask that on jdk-dev and/or build-dev. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Chris, >>>>>>>>>>> >>>>>>>>>>> Thanks for quick reply! >>>>>>>>>>> >>>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to convert a lot of JNI calls to C++ style. >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>>> ????? to >>>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>>> >>>>>>>>>>> Can it be accepted? >>>>>>>>>>> >>>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to link libiberty.a which is provided by binutils. Thus I think we need to check libiberty.a in configure script. Is it ok? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I prefer to use cplus_demangle() if we can change configure script. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in order to do so you've put the new native code in its own file rather than in LinuxDebuggerLocal.c. I'd like to see that resolved. So either convert LinuxDebuggerLocal.c to C++, or use cplus_demangle(). >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were mangled as below: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 0x00007ff255a8fa4c _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread + 0x6ac >>>>>>>>>>>>> 0x00007ff255a8cc1d _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread + 0x33d >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We can demangle them via c++filt, but I think it is more convenience if jstack can show demangling symbols. >>>>>>>>>>>>> I think we can demangle in jstack with this patch. If it is accepted, I will file it to JBS and send review request. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>>> >>>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch adds C++ source to SA. >>>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>>> But this function is provided by libiberty.a, so we need to link it to libsaproc and need to check libiberty.a in configure script. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>> >>> From boris.ulasevich at bell-sw.com Wed Nov 6 14:31:13 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 6 Nov 2019 17:31:13 +0300 Subject: RFR: 8233600: cross-builds fails after JDK-8233285 In-Reply-To: <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> Message-ID: Hi, Indeed, the fix is quite evident. I checked it works for arm32/aarch cross-compilation builds. http://bugs.openjdk.java.net/browse/JDK-8233600 http://cr.openjdk.java.net/~bulasevich/8233600/webrev.00 regards, Boris On 06.11.2019 16:33, Erik Joelsson wrote: > I looked closer at it now and the build change is not good. Any > toolchain definition with BUILD in the name, like > TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools > that are run during the build. I believe the fix is to just remove the > "BUILD_". > > /Erik > > On 2019-11-06 05:13, David Holmes wrote: >> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >>> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>>> Since this review contains build changes, I've added build-dev at ... >>> Thanks Dan for noticing this and cc:ing us. >>> >>> Yasumasa: build changes look fine. Thanks. >> >> This change broke all cross-compilation. >> >> David >> >>> /Magnus >>>> >>>> Dan >>>> >>>> >>>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>>> (Changed subject to review request) >>>>> >>>>> Hi, >>>>> >>>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on >>>>> submit repo. >>>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>>> >>>>> Could you review it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> New build dependencies cannot be added lightly. This impacts >>>>>>> everyone who maintains build/test farms. >>>>>> >>>>>> Ok, thanks for telling it. >>>>>> >>>>>>> We already use the C++ demangling capabilities in the VM. Is >>>>>>> there some way to export that for use by libsaproc ? >>>>>>> >>>>>>> Otherwise using C++ demangle may still be the better choice given >>>>>>> we already have it as a dependency. >>>>>> >>>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() at >>>>>> decoder_linux.cpp . >>>>>> It is similar with my original proposal. >>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>> >>>>>> I agree with David to use C++ demangle way. >>>>>> However we need to choice the fix from following: >>>>>> >>>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>>> >>>>>> I've discussed with Chris about it in [1]. >>>>>> Option A might be large change. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>>> >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Here's the failure during configure: >>>>>>>> >>>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>>>> install binutils-devel'. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I filed this enhancement to JBS: >>>>>>>>> >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>>> >>>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>>> >>>>>>>>> According to the email from Mach 5, dependency errors were >>>>>>>>> occurred in jib. >>>>>>>>> Can someone share the details? >>>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>>> >>>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>>> You can change the configure script. I don't know if there's >>>>>>>>>> any concerns with using libiberty.a. That's possibly a legal >>>>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev >>>>>>>>>> and/or build-dev. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Chris, >>>>>>>>>>> >>>>>>>>>>> Thanks for quick reply! >>>>>>>>>>> >>>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>>> ????? to >>>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>>> >>>>>>>>>>> Can it be accepted? >>>>>>>>>>> >>>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>>>>>> link libiberty.a which is provided by binutils. Thus I think >>>>>>>>>>> we need to check libiberty.a in configure script. Is it ok? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>>>> script. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>>>> order to do so you've put the new native code in its own >>>>>>>>>>>> file rather than in LinuxDebuggerLocal.c. I'd like to see >>>>>>>>>>>> that resolved. So either convert LinuxDebuggerLocal.c to >>>>>>>>>>>> C++, or use cplus_demangle(). >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>>>> mangled as below: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>>>> + 0x6ac >>>>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>>>> + 0x33d >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>>>> I think we can demangle in jstack with this patch. If it is >>>>>>>>>>>>> accepted, I will file it to JBS and send review request. >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>>> >>>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 0x33d >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>>> But this function is provided by libiberty.a, so we need to >>>>>>>>>>>>> link it to libsaproc and need to check libiberty.a in >>>>>>>>>>>>> configure script. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>> >>> From shade at redhat.com Wed Nov 6 16:06:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Nov 2019 17:06:20 +0100 Subject: RFR: 8233600: cross-builds fails after JDK-8233285 In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> Message-ID: <7af7015a-c962-7643-592a-e441e67498bc@redhat.com> On 11/6/19 3:31 PM, Boris Ulasevich wrote: > http://bugs.openjdk.java.net/browse/JDK-8233600 > http://cr.openjdk.java.net/~bulasevich/8233600/webrev.00 This looks good to me. Fixes aarch64 cross-compilation for me. -- Thanks, -Aleksey From erik.joelsson at oracle.com Wed Nov 6 16:18:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 6 Nov 2019 08:18:00 -0800 Subject: RFR: 8233600: cross-builds fails after JDK-8233285 In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> Message-ID: Looks good! Verified the same patch with all our available cross compile builds. /Erik On 2019-11-06 06:31, Boris Ulasevich wrote: > Hi, > > Indeed, the fix is quite evident. I checked it works for arm32/aarch > cross-compilation builds. > > http://bugs.openjdk.java.net/browse/JDK-8233600 > http://cr.openjdk.java.net/~bulasevich/8233600/webrev.00 > > regards, > Boris > > On 06.11.2019 16:33, Erik Joelsson wrote: >> I looked closer at it now and the build change is not good. Any >> toolchain definition with BUILD in the name, like >> TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools >> that are run during the build. I believe the fix is to just remove >> the "BUILD_". >> >> /Erik >> >> On 2019-11-06 05:13, David Holmes wrote: >>> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >>>> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>>>> Since this review contains build changes, I've added build-dev at ... >>>> Thanks Dan for noticing this and cc:ing us. >>>> >>>> Yasumasa: build changes look fine. Thanks. >>> >>> This change broke all cross-compilation. >>> >>> David >>> >>>> /Magnus >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>>>> (Changed subject to review request) >>>>>> >>>>>> Hi, >>>>>> >>>>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine >>>>>> on submit repo. >>>>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>>>> >>>>>> Could you review it? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> New build dependencies cannot be added lightly. This impacts >>>>>>>> everyone who maintains build/test farms. >>>>>>> >>>>>>> Ok, thanks for telling it. >>>>>>> >>>>>>>> We already use the C++ demangling capabilities in the VM. Is >>>>>>>> there some way to export that for use by libsaproc ? >>>>>>>> >>>>>>>> Otherwise using C++ demangle may still be the better choice >>>>>>>> given we already have it as a dependency. >>>>>>> >>>>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() >>>>>>> at decoder_linux.cpp . >>>>>>> It is similar with my original proposal. >>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>> >>>>>>> I agree with David to use C++ demangle way. >>>>>>> However we need to choice the fix from following: >>>>>>> >>>>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>>>> >>>>>>> I've discussed with Chris about it in [1]. >>>>>>> Option A might be large change. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>>>> >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Here's the failure during configure: >>>>>>>>> >>>>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>>>>> install binutils-devel'. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I filed this enhancement to JBS: >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>>>> >>>>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>>>> >>>>>>>>>> According to the email from Mach 5, dependency errors were >>>>>>>>>> occurred in jib. >>>>>>>>>> Can someone share the details? >>>>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>>>> >>>>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>>>> You can change the configure script. I don't know if there's >>>>>>>>>>> any concerns with using libiberty.a. That's possibly a legal >>>>>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev >>>>>>>>>>> and/or build-dev. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Chris, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for quick reply! >>>>>>>>>>>> >>>>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>>>>> For example: >>>>>>>>>>>> >>>>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>>>> ????? to >>>>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>>>> >>>>>>>>>>>> Can it be accepted? >>>>>>>>>>>> >>>>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need >>>>>>>>>>>> to link libiberty.a which is provided by binutils. Thus I >>>>>>>>>>>> think we need to check libiberty.a in configure script. Is >>>>>>>>>>>> it ok? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>>>>> script. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>>>>> order to do so you've put the new native code in its own >>>>>>>>>>>>> file rather than in LinuxDebuggerLocal.c. I'd like to see >>>>>>>>>>>>> that resolved. So either convert LinuxDebuggerLocal.c to >>>>>>>>>>>>> C++, or use cplus_demangle(). >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Chris >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>>>>> mangled as below: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>>>>> + 0x6ac >>>>>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>>>>> + 0x33d >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>>>>> I think we can demangle in jstack with this patch. If it >>>>>>>>>>>>>> is accepted, I will file it to JBS and send review request. >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + >>>>>>>>>>>>>> 0x33d >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>>>> But this function is provided by libiberty.a, so we need >>>>>>>>>>>>>> to link it to libsaproc and need to check libiberty.a in >>>>>>>>>>>>>> configure script. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> From boris.ulasevich at bell-sw.com Wed Nov 6 16:27:57 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 6 Nov 2019 19:27:57 +0300 Subject: RFR: 8233600: cross-builds fails after JDK-8233285 In-Reply-To: References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> Message-ID: <6a7f785c-d9cb-0658-b4b6-09f126f21303@bell-sw.com> Thank you! On 06.11.2019 19:18, Erik Joelsson wrote: > Looks good! Verified the same patch with all our available cross compile > builds. > > /Erik > > On 2019-11-06 06:31, Boris Ulasevich wrote: >> Hi, >> >> Indeed, the fix is quite evident. I checked it works for arm32/aarch >> cross-compilation builds. >> >> http://bugs.openjdk.java.net/browse/JDK-8233600 >> http://cr.openjdk.java.net/~bulasevich/8233600/webrev.00 >> >> regards, >> Boris >> >> On 06.11.2019 16:33, Erik Joelsson wrote: >>> I looked closer at it now and the build change is not good. Any >>> toolchain definition with BUILD in the name, like >>> TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools >>> that are run during the build. I believe the fix is to just remove >>> the "BUILD_". >>> >>> /Erik >>> >>> On 2019-11-06 05:13, David Holmes wrote: >>>> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >>>>> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>>>>> Since this review contains build changes, I've added build-dev at ... >>>>> Thanks Dan for noticing this and cc:ing us. >>>>> >>>>> Yasumasa: build changes look fine. Thanks. >>>> >>>> This change broke all cross-compilation. >>>> >>>> David >>>> >>>>> /Magnus >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>>>>> (Changed subject to review request) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine >>>>>>> on submit repo. >>>>>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>>>>> >>>>>>> Could you review it? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> New build dependencies cannot be added lightly. This impacts >>>>>>>>> everyone who maintains build/test farms. >>>>>>>> >>>>>>>> Ok, thanks for telling it. >>>>>>>> >>>>>>>>> We already use the C++ demangling capabilities in the VM. Is >>>>>>>>> there some way to export that for use by libsaproc ? >>>>>>>>> >>>>>>>>> Otherwise using C++ demangle may still be the better choice >>>>>>>>> given we already have it as a dependency. >>>>>>>> >>>>>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() >>>>>>>> at decoder_linux.cpp . >>>>>>>> It is similar with my original proposal. >>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>> >>>>>>>> I agree with David to use C++ demangle way. >>>>>>>> However we need to choice the fix from following: >>>>>>>> >>>>>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>>>>> >>>>>>>> I've discussed with Chris about it in [1]. >>>>>>>> Option A might be large change. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Here's the failure during configure: >>>>>>>>>> >>>>>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>>>>>> install binutils-devel'. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I filed this enhancement to JBS: >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>>>>> >>>>>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>>>>> >>>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>>>>> >>>>>>>>>>> According to the email from Mach 5, dependency errors were >>>>>>>>>>> occurred in jib. >>>>>>>>>>> Can someone share the details? >>>>>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>>>>> >>>>>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>>>>> You can change the configure script. I don't know if there's >>>>>>>>>>>> any concerns with using libiberty.a. That's possibly a legal >>>>>>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev >>>>>>>>>>>> and/or build-dev. >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi Chris, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for quick reply! >>>>>>>>>>>>> >>>>>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>>>>>> For example: >>>>>>>>>>>>> >>>>>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>>>>> ????? to >>>>>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>>>>> >>>>>>>>>>>>> Can it be accepted? >>>>>>>>>>>>> >>>>>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need >>>>>>>>>>>>> to link libiberty.a which is provided by binutils. Thus I >>>>>>>>>>>>> think we need to check libiberty.a in configure script. Is >>>>>>>>>>>>> it ok? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>>>>>> script. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>>>>>> order to do so you've put the new native code in its own >>>>>>>>>>>>>> file rather than in LinuxDebuggerLocal.c. I'd like to see >>>>>>>>>>>>>> that resolved. So either convert LinuxDebuggerLocal.c to >>>>>>>>>>>>>> C++, or use cplus_demangle(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Chris >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>>>>>> mangled as below: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>>>>>> + 0x6ac >>>>>>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>>>>>> + 0x33d >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>>>>>> I think we can demangle in jstack with this patch. If it >>>>>>>>>>>>>>> is accepted, I will file it to JBS and send review request. >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + >>>>>>>>>>>>>>> 0x33d >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>>>>> But this function is provided by libiberty.a, so we need >>>>>>>>>>>>>>> to link it to libsaproc and need to check libiberty.a in >>>>>>>>>>>>>>> configure script. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>> From david.holmes at oracle.com Thu Nov 7 00:04:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Nov 2019 10:04:24 +1000 Subject: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed In-Reply-To: <832479a6-dbb5-00ed-5ef6-18a1b4b71151@oss.nttdata.com> References: <14a3ed2c-ccd8-83bb-d4f1-d3a319fa2b8a@oracle.com> <81e1e086-6b54-fe6c-f78b-9b2b543b9dcb@oracle.com> <86dc525b-7f4a-2cbd-5893-37fb8ebe4c59@oss.nttdata.com> <644a2d61-ac4b-0106-76fa-8e63d8412a89@oracle.com> <1fd10248-13e9-16ed-6730-e7d530bbd6af@oracle.com> <2e06b688-d3bb-9cb7-e221-62c3462a308f@oracle.com> <832479a6-dbb5-00ed-5ef6-18a1b4b71151@oss.nttdata.com> Message-ID: <2b994a58-56d5-5dfd-05f8-3c4800863632@oracle.com> Just for the record this was fixed by "8233600: cross-builds fails after JDK-8233285" David On 6/11/2019 11:50 pm, Yasumasa Suenaga wrote: > Hi, > > Thanks for telling it me. > I removed "BUILD_" from Makefile as Erik said, then it works fine on my > Linux box: > > ``` > diff -r a3b046720c3b make/lib/Lib-jdk.hotspot.agent.gmk > --- a/make/lib/Lib-jdk.hotspot.agent.gmk??????? Wed Nov 06 21:49:30 2019 > +0900 > +++ b/make/lib/Lib-jdk.hotspot.agent.gmk??????? Wed Nov 06 22:48:00 2019 > +0900 > @@ -55,7 +55,7 @@ > > ?SA_TOOLCHAIN := $(TOOLCHAIN_DEFAULT) > ?ifeq ($(call isTargetOs, linux), true) > -? SA_TOOLCHAIN := TOOLCHAIN_BUILD_LINK_CXX > +? SA_TOOLCHAIN := TOOLCHAIN_LINK_CXX > ?endif > > ?################################################################################ > ``` > > Could you file it to JBS? I don't know details. > If you assign it to me, I will send review request. > > > Thanks, > > Yasumasa > > > On 2019/11/06 22:33, Erik Joelsson wrote: >> I looked closer at it now and the build change is not good. Any >> toolchain definition with BUILD in the name, like >> TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools >> that are run during the build. I believe the fix is to just remove the >> "BUILD_". >> >> /Erik >> >> On 2019-11-06 05:13, David Holmes wrote: >>> On 4/11/2019 8:27 pm, Magnus Ihse Bursie wrote: >>>> On 2019-11-02 13:43, Daniel D. Daugherty wrote: >>>>> Since this review contains build changes, I've added build-dev at ... >>>> Thanks Dan for noticing this and cc:ing us. >>>> >>>> Yasumasa: build changes look fine. Thanks. >>> >>> This change broke all cross-compilation. >>> >>> David >>> >>>> /Magnus >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: >>>>>> (Changed subject to review request) >>>>>> >>>>>> Hi, >>>>>> >>>>>> I converted LinuxDebuggerLocal.c to C++ code, and it works fine on >>>>>> submit repo. >>>>>> (mach5-one-ysuenaga-JDK-8233285-1-20191101-0746-6336009) >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8233285/webrev.00/ >>>>>> >>>>>> Could you review it? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/11/01 8:54, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 2019/11/01 7:55, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> New build dependencies cannot be added lightly. This impacts >>>>>>>> everyone who maintains build/test farms. >>>>>>> >>>>>>> Ok, thanks for telling it. >>>>>>> >>>>>>>> We already use the C++ demangling capabilities in the VM. Is >>>>>>>> there some way to export that for use by libsaproc ? >>>>>>>> >>>>>>>> Otherwise using C++ demangle may still be the better choice >>>>>>>> given we already have it as a dependency. >>>>>>> >>>>>>> I found abi::__cxa_demangle() is used in ElfDecoder::demangle() >>>>>>> at decoder_linux.cpp . >>>>>>> It is similar with my original proposal. >>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>> >>>>>>> I agree with David to use C++ demangle way. >>>>>>> However we need to choice the fix from following: >>>>>>> >>>>>>> ?? A. Convert LinuxDebuggerLocal.c to C++ code >>>>>>> ?? B. Add C++ code for libsaproc.so to demangle symbols. >>>>>>> >>>>>>> I've discussed with Chris about it in [1]. >>>>>>> Option A might be large change. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029716.html >>>>>>> >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 1/11/2019 12:58 am, Chris Plummer wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Here's the failure during configure: >>>>>>>>> >>>>>>>>> [2019-10-31T06:07:45,131Z] checking demangle.h usability... no >>>>>>>>> [2019-10-31T06:07:45,150Z] checking demangle.h presence... no >>>>>>>>> [2019-10-31T06:07:45,150Z] checking for demangle.h... no >>>>>>>>> [2019-10-31T06:07:45,151Z] configure: error: Could not find >>>>>>>>> demangle.h! You might be able to fix this by running 'sudo yum >>>>>>>>> install binutils-devel'. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/31/19 1:08 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I filed this enhancement to JBS: >>>>>>>>>> >>>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8233285 >>>>>>>>>> >>>>>>>>>> Also I pushed the changes to submit repo, but it was failed. >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/bfbc49233c26 >>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/430e4f65ef25 >>>>>>>>>> >>>>>>>>>> According to the email from Mach 5, dependency errors were >>>>>>>>>> occurred in jib. >>>>>>>>>> Can someone share the details? >>>>>>>>>> I'm not familiar in jib, so I want help. >>>>>>>>>> >>>>>>>>>> mach5-one-ysuenaga-JDK-8233285-20191031-0606-6301426 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/10/31 11:23, Chris Plummer wrote: >>>>>>>>>>> You can change the configure script. I don't know if there's >>>>>>>>>>> any concerns with using libiberty.a. That's possibly a legal >>>>>>>>>>> question (GNU GPL). You might want to ask that on jdk-dev >>>>>>>>>>> and/or build-dev. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 10/30/19 7:14 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Chris, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for quick reply! >>>>>>>>>>>> >>>>>>>>>>>> If we convert LinuxDebuggerLocal.c to C++ code, we have to >>>>>>>>>>>> convert a lot of JNI calls to C++ style. >>>>>>>>>>>> For example: >>>>>>>>>>>> >>>>>>>>>>>> ? (*env)->FindClass(env, "java/lang/String") >>>>>>>>>>>> ????? to >>>>>>>>>>>> ? env->FindClass("java/lang/String") >>>>>>>>>>>> >>>>>>>>>>>> Can it be accepted? >>>>>>>>>>>> >>>>>>>>>>>> OTOH I said in my email, to use cplus_demangle(), we need to >>>>>>>>>>>> link libiberty.a which is provided by binutils. Thus I think >>>>>>>>>>>> we need to check libiberty.a in configure script. Is it ok? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I prefer to use cplus_demangle() if we can change configure >>>>>>>>>>>> script. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2019/10/31 11:03, Chris Plummer wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't have concerns with adding C++ source to SA, but in >>>>>>>>>>>>> order to do so you've put the new native code in its own >>>>>>>>>>>>> file rather than in LinuxDebuggerLocal.c. I'd like to see >>>>>>>>>>>>> that resolved. So either convert LinuxDebuggerLocal.c to >>>>>>>>>>>>> C++, or use cplus_demangle(). >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Chris >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/30/19 6:54 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I saw C++ frames in `jhsdb jstack --mixed`, and they were >>>>>>>>>>>>>> mangled as below: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 0x00007ff255a8fa4c >>>>>>>>>>>>>> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread >>>>>>>>>>>>>> + 0x6ac >>>>>>>>>>>>>> 0x00007ff255a8cc1d >>>>>>>>>>>>>> _ZN9JavaCalls12call_virtualEP9JavaValueP5KlassP6SymbolS5_P17JavaCallArgumentsP6Thread >>>>>>>>>>>>>> + 0x33d >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can demangle them via c++filt, but I think it is more >>>>>>>>>>>>>> convenience if jstack can show demangling symbols. >>>>>>>>>>>>>> I think we can demangle in jstack with this patch. If it >>>>>>>>>>>>>> is accepted, I will file it to JBS and send review request. >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/sa-demangle/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can get the stack as below after applying this patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 0x00007ff1aba20a4c JavaCalls::call_helper(JavaValue*, >>>>>>>>>>>>>> methodHandle const&, JavaCallArguments*, Thread*) + 0x6ac >>>>>>>>>>>>>> 0x00007ff1aba1dc1d JavaCalls::call_virtual(JavaValue*, >>>>>>>>>>>>>> Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*) + >>>>>>>>>>>>>> 0x33d >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I use abi::__cxa_demangle() for demangling, so this patch >>>>>>>>>>>>>> adds C++ source to SA. >>>>>>>>>>>>>> If it is not comfortable, we can use cplus_demangle(). >>>>>>>>>>>>>> But this function is provided by libiberty.a, so we need >>>>>>>>>>>>>> to link it to libsaproc and need to check libiberty.a in >>>>>>>>>>>>>> configure script. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> From sgehwolf at redhat.com Thu Nov 7 14:59:24 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Nov 2019 15:59:24 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting Message-ID: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> Hi, Could I please get a review of this change for running tests on big Aarch64 boxes? Currently, only memory and number of cores are taken into account for the -concurrency setting of jtreg. After this patch ulimit -u settings are taken into account as well on big Aarch64 boxes with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid running into the max allowed threads limit causing random test failures. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u value. Tests run stable. Did the same for a user with high ulimit -u value, which resulted in concurrency setting as before this patch. Thanks, Severin From erik.joelsson at oracle.com Thu Nov 7 18:01:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Nov 2019 10:01:09 -0800 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> Message-ID: <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> Hello Severin, Taking ulimit -u into account does seem like a good idea. I don't see why it needs to be limited to just aarch64 though. It should however be limited to OSes that use ulimit (i.e. not windows). I would suggest removing the arbitrary thresholds of 16 and 4096 and try to come up with a plain number based on the ulimit value. You are saying 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, which you can just write as: ULIMIT_DIVIER := (4096 / 14) And let the awk script calculate it if needed. In the awk script, you need to put line 275 as conditional of the if statement on line 274. Otherwise ULIMIT=-1 will cause concurrency -1. /Erik On 2019-11-07 06:59, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this change for running tests on big > Aarch64 boxes? Currently, only memory and number of cores are taken > into account for the -concurrency setting of jtreg. After this patch > ulimit -u settings are taken into account as well on big Aarch64 boxes > with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid > running into the max allowed threads limit causing random test > failures. > > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ > > Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u > value. Tests run stable. Did the same for a user with high ulimit -u > value, which resulted in concurrency setting as before this patch. > > Thanks, > Severin > From sgehwolf at redhat.com Thu Nov 7 19:48:15 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Nov 2019 20:48:15 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> Message-ID: <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> Hi Erik, On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: > Hello Severin, > > Taking ulimit -u into account does seem like a good idea. I don't see > why it needs to be limited to just aarch64 though. It should however be > limited to OSes that use ulimit (i.e. not windows). > > I would suggest removing the arbitrary thresholds of 16 and 4096 and try > to come up with a plain number based on the ulimit value. You are saying > 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, > which you can just write as: > > ULIMIT_DIVIER := (4096 / 14) > > And let the awk script calculate it if needed. In the awk script, you > need to put line 275 as conditional of the if statement on line 274. > Otherwise ULIMIT=-1 will cause concurrency -1. Thanks for the review! Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ What do you think? Thanks, Severin > /Erik > > On 2019-11-07 06:59, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this change for running tests on big > > Aarch64 boxes? Currently, only memory and number of cores are taken > > into account for the -concurrency setting of jtreg. After this patch > > ulimit -u settings are taken into account as well on big Aarch64 boxes > > with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid > > running into the max allowed threads limit causing random test > > failures. > > > > Thoughts? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ > > > > Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u > > value. Tests run stable. Did the same for a user with high ulimit -u > > value, which resulted in concurrency setting as before this patch. > > > > Thanks, > > Severin > > From erik.joelsson at oracle.com Thu Nov 7 21:54:29 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Nov 2019 13:54:29 -0800 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> Message-ID: <66c086aa-c708-c494-bbb1-9902f0398212@oracle.com> Looks good. /Erik On 2019-11-07 11:48, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> Taking ulimit -u into account does seem like a good idea. I don't see >> why it needs to be limited to just aarch64 though. It should however be >> limited to OSes that use ulimit (i.e. not windows). >> >> I would suggest removing the arbitrary thresholds of 16 and 4096 and try >> to come up with a plain number based on the ulimit value. You are saying >> 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, >> which you can just write as: >> >> ULIMIT_DIVIER := (4096 / 14) >> >> And let the awk script calculate it if needed. In the awk script, you >> need to put line 275 as conditional of the if statement on line 274. >> Otherwise ULIMIT=-1 will cause concurrency -1. > Thanks for the review! Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ > > What do you think? > > Thanks, > Severin > >> /Erik >> >> On 2019-11-07 06:59, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get a review of this change for running tests on big >>> Aarch64 boxes? Currently, only memory and number of cores are taken >>> into account for the -concurrency setting of jtreg. After this patch >>> ulimit -u settings are taken into account as well on big Aarch64 boxes >>> with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid >>> running into the max allowed threads limit causing random test >>> failures. >>> >>> Thoughts? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ >>> >>> Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u >>> value. Tests run stable. Did the same for a user with high ulimit -u >>> value, which resulted in concurrency setting as before this patch. >>> >>> Thanks, >>> Severin >>> From magnus.ihse.bursie at oracle.com Fri Nov 8 08:58:04 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Nov 2019 09:58:04 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> Message-ID: <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> On 2019-11-07 20:48, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> Taking ulimit -u into account does seem like a good idea. I don't see >> why it needs to be limited to just aarch64 though. It should however be >> limited to OSes that use ulimit (i.e. not windows). >> >> I would suggest removing the arbitrary thresholds of 16 and 4096 and try >> to come up with a plain number based on the ulimit value. You are saying >> 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, >> which you can just write as: >> >> ULIMIT_DIVIER := (4096 / 14) >> >> And let the awk script calculate it if needed. In the awk script, you >> need to put line 275 as conditional of the if statement on line 274. >> Otherwise ULIMIT=-1 will cause concurrency -1. > Thanks for the review! Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ I know I'm coming here and making a simple patch more complicated, but I'm not entirely comfortable with the explicit call to ulimit. Our principle is that all executables that we call from the makefiles should be confirmed existing by configure, so the call should be "$(shell $(ULIMIT) -u)". It should be relatively trivial to add this as a required prog in basics.m4 and spec.gmk.in. Make sure you only add it as required for non-Windows platforms. If you do this, you can change the check in the makefile to if $(ULIMIT) has a value, rather than checking on platform. /Magnus > > What do you think? > > Thanks, > Severin > >> /Erik >> >> On 2019-11-07 06:59, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get a review of this change for running tests on big >>> Aarch64 boxes? Currently, only memory and number of cores are taken >>> into account for the -concurrency setting of jtreg. After this patch >>> ulimit -u settings are taken into account as well on big Aarch64 boxes >>> with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid >>> running into the max allowed threads limit causing random test >>> failures. >>> >>> Thoughts? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ >>> >>> Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u >>> value. Tests run stable. Did the same for a user with high ulimit -u >>> value, which resulted in concurrency setting as before this patch. >>> >>> Thanks, >>> Severin >>> From sgehwolf at redhat.com Fri Nov 8 09:19:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Nov 2019 10:19:18 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> Message-ID: On Fri, 2019-11-08 at 09:58 +0100, Magnus Ihse Bursie wrote: > On 2019-11-07 20:48, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > Taking ulimit -u into account does seem like a good idea. I don't see > > > why it needs to be limited to just aarch64 though. It should however be > > > limited to OSes that use ulimit (i.e. not windows). > > > > > > I would suggest removing the arbitrary thresholds of 16 and 4096 and try > > > to come up with a plain number based on the ulimit value. You are saying > > > 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, > > > which you can just write as: > > > > > > ULIMIT_DIVIER := (4096 / 14) > > > > > > And let the awk script calculate it if needed. In the awk script, you > > > need to put line 275 as conditional of the if statement on line 274. > > > Otherwise ULIMIT=-1 will cause concurrency -1. > > Thanks for the review! Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ > I know I'm coming here and making a simple patch more complicated, but > I'm not entirely comfortable with the explicit call to ulimit. Our > principle is that all executables that we call from the makefiles should > be confirmed existing by configure, so the call should be "$(shell > $(ULIMIT) -u)". > > It should be relatively trivial to add this as a required prog in > basics.m4 and spec.gmk.in. Make sure you only add it as required for > non-Windows platforms. If you do this, you can change the check in the > makefile to if $(ULIMIT) has a value, rather than checking on platform. Sure, will do. Thanks Magnus! Cheers, Severin > /Magnus > > What do you think? > > > > Thanks, > > Severin > > > > > /Erik > > > > > > On 2019-11-07 06:59, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get a review of this change for running tests on big > > > > Aarch64 boxes? Currently, only memory and number of cores are taken > > > > into account for the -concurrency setting of jtreg. After this patch > > > > ulimit -u settings are taken into account as well on big Aarch64 boxes > > > > with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid > > > > running into the max allowed threads limit causing random test > > > > failures. > > > > > > > > Thoughts? > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ > > > > > > > > Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u > > > > value. Tests run stable. Did the same for a user with high ulimit -u > > > > value, which resulted in concurrency setting as before this patch. > > > > > > > > Thanks, > > > > Severin > > > > From hoffmann at mountainminds.com Fri Nov 8 09:59:51 2019 From: hoffmann at mountainminds.com (Marc Hoffmann) Date: Fri, 08 Nov 2019 10:59:51 +0100 Subject: Fixing compiler warnings in src/demo/share/jfc In-Reply-To: <6e8392b6-8030-9314-7de6-31c2427c4b83@oracle.com> References: <0663E469-9C0C-4B56-AE27-A318B6583556@mountainminds.com> <6e8392b6-8030-9314-7de6-31c2427c4b83@oracle.com> Message-ID: <32aa3337c2f6477f378ed9461e7b9224@mountainminds.com> Dear Magnus, as advised I signed the OCA and it was quickly approved (thanks to Dalibor!). I also posted my proposal to swing-dev (https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html) but with no response so far. Do you have an idea what other strings I can pull to find a sponsor at the Swing dev team? Regards, -marc On 2019-10-29 13:21, Magnus Ihse Bursie wrote: > Hi, > > Thank you for fixing this, and for your nice workds about the OpenJDK build system! Those warnings have annoyed me to, and I'm glad to see that someone has stepped up to fix them. > > Unfortunately, making a first time contribution to OpenJDK is somewhat cumbersome, since this is a large and very formal project. This page will give you most of the instructions you need: https://openjdk.java.net/contribute. As a minimum, you need to sign the OCA. Without this, we can unfortunately do nothing more with your patches. :-( > > And as David said, these fixes will need to be approved by folks in swing-dev at openjdk.java.net. However, fixing warnings in the build do indeed intersect with build issues, so you feel free to cross-post the discussion here. > > Let me know if you run into too much friction in the process, and want me to assist you to shepherd these fixes. I know getting your first patch in can be a bit rough. > > /Magnus > > On 2019-10-23 19:59, Marc Hoffmann wrote: > >> MOTIVATION >> >> As a developer of the JaCoCo code coverage library I do lots of JDK builds. JDK >> builds are simple, fast and produce minimal log output. Nice! What annoys me >> though are plenty of compiler warnings at the end of the build caused by the >> example code in src/demo/share/jfc >> >> FIX >> >> I propose a series of 3 patches (based on each other) which fixes all compiler >> warnings for the demos: >> >> patch1.txt - Fix compiler warnings in demos: raw types >> patch2.txt - Fix compiler warnings in demos: deprecated APIs >> patch3.txt - Fix compiler warnings in demos: deprecated Applet APIs >> >> While patch 1 & 2 do not change functionality patch 3 actually removes the >> Applet versions of some of the demos. The java main versions of the same demos >> are still intact. >> >> The patches are based on changeset 56699:70e6b0d8db13. >> >> They have been tested from this clone: https://github.com/marchof/jdk/tree/fix-compiler-warnings-in-demos >> >> RESULT >> >> All compiler warnings on demo code during JDK build are removed >> >> TESTING >> >> I haven't found any automated tests so I manually launched all the demos. From >> what I can say they are still functional. >> >> SCOPE >> >> I applied minimal changes to remove compiler warnings only. There are many more >> cleanup opportunities in the demo code. Also there is (dead?) code in >> src/demo/share/java2d which has similar issues. Both are not on scope of these >> patches. >> >> NEXT STEPS >> >> I'm have no experience with OpenJDK patches. If you're interested in getting these warnings fixed please >> let me know how I can submit these patches properly. From sgehwolf at redhat.com Fri Nov 8 10:26:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Nov 2019 11:26:02 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> Message-ID: On Fri, 2019-11-08 at 09:58 +0100, Magnus Ihse Bursie wrote: > On 2019-11-07 20:48, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > Taking ulimit -u into account does seem like a good idea. I don't see > > > why it needs to be limited to just aarch64 though. It should however be > > > limited to OSes that use ulimit (i.e. not windows). > > > > > > I would suggest removing the arbitrary thresholds of 16 and 4096 and try > > > to come up with a plain number based on the ulimit value. You are saying > > > 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, > > > which you can just write as: > > > > > > ULIMIT_DIVIER := (4096 / 14) > > > > > > And let the awk script calculate it if needed. In the awk script, you > > > need to put line 275 as conditional of the if statement on line 274. > > > Otherwise ULIMIT=-1 will cause concurrency -1. > > Thanks for the review! Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ > I know I'm coming here and making a simple patch more complicated, but > I'm not entirely comfortable with the explicit call to ulimit. Our > principle is that all executables that we call from the makefiles should > be confirmed existing by configure, so the call should be "$(shell > $(ULIMIT) -u)". > > It should be relatively trivial to add this as a required prog in > basics.m4 and spec.gmk.in. Make sure you only add it as required for > non-Windows platforms. If you do this, you can change the check in the > makefile to if $(ULIMIT) has a value, rather than checking on platform. Here you go: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/03/webrev/ Thanks, Severin > /Magnus > > What do you think? > > > > Thanks, > > Severin > > > > > /Erik > > > > > > On 2019-11-07 06:59, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get a review of this change for running tests on big > > > > Aarch64 boxes? Currently, only memory and number of cores are taken > > > > into account for the -concurrency setting of jtreg. After this patch > > > > ulimit -u settings are taken into account as well on big Aarch64 boxes > > > > with > 16 cores, yet low ulimit -u setting (<= 4096). This is to avoid > > > > running into the max allowed threads limit causing random test > > > > failures. > > > > > > > > Thoughts? > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233712 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/01/webrev/ > > > > > > > > Testing: Ran tier1 tests on a large Aarch64 box and low ulimit -u > > > > value. Tests run stable. Did the same for a user with high ulimit -u > > > > value, which resulted in concurrency setting as before this patch. > > > > > > > > Thanks, > > > > Severin > > > > From jorn.vernee at oracle.com Fri Nov 8 12:24:01 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 8 Nov 2019 13:24:01 +0100 Subject: RFR 8233844: Add LogCompilation build artifacts to .gitignore Message-ID: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> Hi, I'd like to contribute this very small patch that adds some LogCompilation build artifacts to the .gitignore file. Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 Webrev: http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html Testing = manual FWIW, it seems that these artifacts are produced at some point either while doing a vanilla build, or when running the test, so these artifacts will show up pretty much always when using Git (AFAICS I have them in all my OpenJDK Git repos, and I've never directly used this utility). So, it seems worth it to gitnore them. As a heads-up; I'm not a committer on the JDK project, so a sponsor would need to push this. Thanks, Jorn From sgehwolf at redhat.com Fri Nov 8 13:08:05 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Nov 2019 14:08:05 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> Message-ID: <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> On Fri, 2019-11-08 at 11:26 +0100, Severin Gehwolf wrote: > On Fri, 2019-11-08 at 09:58 +0100, Magnus Ihse Bursie wrote: > > On 2019-11-07 20:48, Severin Gehwolf wrote: > > > Hi Erik, > > > > > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: > > > > Hello Severin, > > > > > > > > Taking ulimit -u into account does seem like a good idea. I don't see > > > > why it needs to be limited to just aarch64 though. It should however be > > > > limited to OSes that use ulimit (i.e. not windows). > > > > > > > > I would suggest removing the arbitrary thresholds of 16 and 4096 and try > > > > to come up with a plain number based on the ulimit value. You are saying > > > > 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, > > > > which you can just write as: > > > > > > > > ULIMIT_DIVIER := (4096 / 14) > > > > > > > > And let the awk script calculate it if needed. In the awk script, you > > > > need to put line 275 as conditional of the if statement on line 274. > > > > Otherwise ULIMIT=-1 will cause concurrency -1. > > > Thanks for the review! Updated webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ > > I know I'm coming here and making a simple patch more complicated, but > > I'm not entirely comfortable with the explicit call to ulimit. Our > > principle is that all executables that we call from the makefiles should > > be confirmed existing by configure, so the call should be "$(shell > > $(ULIMIT) -u)". > > > > It should be relatively trivial to add this as a required prog in > > basics.m4 and spec.gmk.in. Make sure you only add it as required for > > non-Windows platforms. If you do this, you can change the check in the > > makefile to if $(ULIMIT) has a value, rather than checking on platform. > > Here you go: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/03/webrev/ Hmm, this failed jdk/submit. Could anybody provide me with some details, please? [Mach5] mach5-one-sgehwolf-JDK-8233712-3-20191108-1036-6526715: FAILED Thanks, Severin From erik.joelsson at oracle.com Fri Nov 8 14:06:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Nov 2019 06:06:20 -0800 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> Message-ID: Hello Severin, On 2019-11-08 05:08, Severin Gehwolf wrote: > On Fri, 2019-11-08 at 11:26 +0100, Severin Gehwolf wrote: >> On Fri, 2019-11-08 at 09:58 +0100, Magnus Ihse Bursie wrote: >>> On 2019-11-07 20:48, Severin Gehwolf wrote: >>>> Hi Erik, >>>> >>>> On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: >>>>> Hello Severin, >>>>> >>>>> Taking ulimit -u into account does seem like a good idea. I don't see >>>>> why it needs to be limited to just aarch64 though. It should however be >>>>> limited to OSes that use ulimit (i.e. not windows). >>>>> >>>>> I would suggest removing the arbitrary thresholds of 16 and 4096 and try >>>>> to come up with a plain number based on the ulimit value. You are saying >>>>> 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, >>>>> which you can just write as: >>>>> >>>>> ULIMIT_DIVIER := (4096 / 14) >>>>> >>>>> And let the awk script calculate it if needed. In the awk script, you >>>>> need to put line 275 as conditional of the if statement on line 274. >>>>> Otherwise ULIMIT=-1 will cause concurrency -1. >>>> Thanks for the review! Updated webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ >>> I know I'm coming here and making a simple patch more complicated, but >>> I'm not entirely comfortable with the explicit call to ulimit. Our >>> principle is that all executables that we call from the makefiles should >>> be confirmed existing by configure, so the call should be "$(shell >>> $(ULIMIT) -u)". >>> >>> It should be relatively trivial to add this as a required prog in >>> basics.m4 and spec.gmk.in. Make sure you only add it as required for >>> non-Windows platforms. If you do this, you can change the check in the >>> makefile to if $(ULIMIT) has a value, rather than checking on platform. Unfortunately ulimit exists in Cygwin but I it's unclear what it does. On my 32 threads Windows machine, it currently has value 256 for -u, which would severely limit testing for no good reason. I think we need to keep explicitly not doing this on Windows. >> Here you go: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/03/webrev/ > Hmm, this failed jdk/submit. Could anybody provide me with some > details, please? > > [Mach5] mach5-one-sgehwolf-JDK-8233712-3-20191108-1036-6526715: FAILED The problem is that when we run tests in our distributed system, we don't run configure on the test node, but instead use the "run-test-prebuilt" make target. For any tool configure needs to discover, that is also used in RunTest.gmk, there needs to be a backup discovery method in RunTestPrebuiltSpec.gmk. It's currently just a list of hardcoded values. So add "ULIMIT := ulimit" there and it should work. /Erik > Thanks, > Severin > From erik.joelsson at oracle.com Fri Nov 8 14:16:31 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Nov 2019 06:16:31 -0800 Subject: RFR 8233844: Add LogCompilation build artifacts to .gitignore In-Reply-To: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> References: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> Message-ID: <8236c9fa-2264-791b-42c3-b864ef72c765@oracle.com> Hello Jorn, On 2019-11-08 04:24, Jorn Vernee wrote: > Hi, > > I'd like to contribute this very small patch that adds some > LogCompilation build artifacts to the .gitignore file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 > Webrev: http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html > > Testing = manual > > FWIW, it seems that these artifacts are produced at some point either > while doing a vanilla build, or when running the test, so these > artifacts will show up pretty much always when using Git (AFAICS I > have them in all my OpenJDK Git repos, and I've never directly used > this utility). So, it seems worth it to gitnore them. > I've never seen these artifacts, and the only way I can see them being created is if you explicitly invoke the maven build for LogCompilation (which of course is a perfectly valid thing to do). The .classpath, .project and .settings files are eclipse project files and it could be argued that those should be put on ignore regardless of where in the source tree they are found, just like we already do for .idea. When adding this for .gitignore, I would prefer if we could keep parity with .hgignore so please add it there too. /Erik > As a heads-up; I'm not a committer on the JDK project, so a sponsor > would need to push this. > > Thanks, > Jorn > From sgehwolf at redhat.com Fri Nov 8 15:48:55 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Nov 2019 16:48:55 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> Message-ID: <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> On Fri, 2019-11-08 at 06:06 -0800, Erik Joelsson wrote: > Hello Severin, > > On 2019-11-08 05:08, Severin Gehwolf wrote: > > On Fri, 2019-11-08 at 11:26 +0100, Severin Gehwolf wrote: > > > On Fri, 2019-11-08 at 09:58 +0100, Magnus Ihse Bursie wrote: > > > > On 2019-11-07 20:48, Severin Gehwolf wrote: > > > > > Hi Erik, > > > > > > > > > > On Thu, 2019-11-07 at 10:01 -0800, Erik Joelsson wrote: > > > > > > Hello Severin, > > > > > > > > > > > > Taking ulimit -u into account does seem like a good idea. I don't see > > > > > > why it needs to be limited to just aarch64 though. It should however be > > > > > > limited to OSes that use ulimit (i.e. not windows). > > > > > > > > > > > > I would suggest removing the arbitrary thresholds of 16 and 4096 and try > > > > > > to come up with a plain number based on the ulimit value. You are saying > > > > > > 14 is good for 4096, so the formula for the ULIMIT_DIVIDER is 4096 / 14, > > > > > > which you can just write as: > > > > > > > > > > > > ULIMIT_DIVIER := (4096 / 14) > > > > > > > > > > > > And let the awk script calculate it if needed. In the awk script, you > > > > > > need to put line 275 as conditional of the if statement on line 274. > > > > > > Otherwise ULIMIT=-1 will cause concurrency -1. > > > > > Thanks for the review! Updated webrev: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/02/webrev/ > > > > I know I'm coming here and making a simple patch more complicated, but > > > > I'm not entirely comfortable with the explicit call to ulimit. Our > > > > principle is that all executables that we call from the makefiles should > > > > be confirmed existing by configure, so the call should be "$(shell > > > > $(ULIMIT) -u)". > > > > > > > > It should be relatively trivial to add this as a required prog in > > > > basics.m4 and spec.gmk.in. Make sure you only add it as required for > > > > non-Windows platforms. If you do this, you can change the check in the > > > > makefile to if $(ULIMIT) has a value, rather than checking on platform. > Unfortunately ulimit exists in Cygwin but I it's unclear what it does. > On my 32 threads Windows machine, it currently has value 256 for -u, > which would severely limit testing for no good reason. I think we need > to keep explicitly not doing this on Windows. Right. I believe webrev 03 does this? > > > Here you go: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/03/webrev/ > > Hmm, this failed jdk/submit. Could anybody provide me with some > > details, please? > > > > [Mach5] mach5-one-sgehwolf-JDK-8233712-3-20191108-1036-6526715: FAILED > > The problem is that when we run tests in our distributed system, we > don't run configure on the test node, but instead use the > "run-test-prebuilt" make target. For any tool configure needs to > discover, that is also used in RunTest.gmk, there needs to be a backup > discovery method in RunTestPrebuiltSpec.gmk. It's currently just a list > of hardcoded values. So add "ULIMIT := ulimit" there and it should work. Thanks! Tried it, which doesn't seem to work[1]: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/04/webrev/ Is there some way to reproduce locally? Thanks, Severin [1] [Mach5] mach5-one-sgehwolf-JDK-8233712-4-20191108-1454-6533841: FAILED > /Erik > > > Thanks, > > Severin > > From erik.joelsson at oracle.com Fri Nov 8 16:57:25 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 8 Nov 2019 08:57:25 -0800 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> Message-ID: <06d84de7-b05e-a4a2-7a01-e604cd1f7c7e@oracle.com> Hello Severin, On 2019-11-08 07:48, Severin Gehwolf wrote: > > Right. I believe webrev 03 does this? Yes, that was mostly a reply to Magnus. > > Thanks! Tried it, which doesn't seem to work[1]: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/04/webrev/ Looking at your job, it's failing already in configure on our Linux hosts. At least on Oracle Linux, it seems ulimit is a bash builtin and not found in path. Configure needs to fallback on that. /Erik > Is there some way to reproduce locally? > > Thanks, > Severin > > [1] [Mach5] mach5-one-sgehwolf-JDK-8233712-4-20191108-1454-6533841: FAILED > >> /Erik >> >>> Thanks, >>> Severin >>> From jorn.vernee at oracle.com Fri Nov 8 17:48:56 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 8 Nov 2019 18:48:56 +0100 Subject: RFR 8233844: Add LogCompilation build artifacts to .gitignore In-Reply-To: <8236c9fa-2264-791b-42c3-b864ef72c765@oracle.com> References: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> <8236c9fa-2264-791b-42c3-b864ef72c765@oracle.com> Message-ID: <70cacf73-9ff3-8cb3-c15b-22b126dea5de@oracle.com> Hello Erik, You are right, I spoke too soon. I deleted the artifacts and tried to trigger the creation by doing a clean build and running some tests, but neither seems to generate the artifacts. I'm really puzzled by this, since I have 4 repos that contain these artifacts (both git and hg), and I'm certain that I've never explicitly built this utility using maven (I've never used it. I can imagine building it once and not remembering, but not 4 times). Any way, here is the updated webrev: http://cr.openjdk.java.net/~jvernee/8233844/webrev.02 I'll keep an eye out for these artifacts appearing again. Thanks, Jorn On 08/11/2019 15:16, Erik Joelsson wrote: > Hello Jorn, > > On 2019-11-08 04:24, Jorn Vernee wrote: >> Hi, >> >> I'd like to contribute this very small patch that adds some >> LogCompilation build artifacts to the .gitignore file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 >> Webrev: http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html >> >> Testing = manual >> >> FWIW, it seems that these artifacts are produced at some point either >> while doing a vanilla build, or when running the test, so these >> artifacts will show up pretty much always when using Git (AFAICS I >> have them in all my OpenJDK Git repos, and I've never directly used >> this utility). So, it seems worth it to gitnore them. >> > I've never seen these artifacts, and the only way I can see them being > created is if you explicitly invoke the maven build for LogCompilation > (which of course is a perfectly valid thing to do). The .classpath, > .project and .settings files are eclipse project files and it could be > argued that those should be put on ignore regardless of where in the > source tree they are found, just like we already do for .idea. When > adding this for .gitignore, I would prefer if we could keep parity > with .hgignore so please add it there too. > > /Erik > >> As a heads-up; I'm not a committer on the JDK project, so a sponsor >> would need to push this. >> >> Thanks, >> Jorn >> From fweimer at redhat.com Sat Nov 9 09:38:51 2019 From: fweimer at redhat.com (Florian Weimer) Date: Sat, 09 Nov 2019 10:38:51 +0100 Subject: RFR 8233880: Support compilers with multi-digit major version numbers Message-ID: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> The current regular expression only matches one digit before the first dot. Bug: Webrev: Tested against GCC 10.0.0. configure no longer prints a C/C++ version mismatch warning. Thanks, Florian From tim.bell at oracle.com Sat Nov 9 14:19:21 2019 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 9 Nov 2019 06:19:21 -0800 Subject: RFR 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> References: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> Message-ID: <9d20aa41-86f6-9a27-4480-7f248addc5f4@oracle.com> Florian: > The current regular expression only matches one digit before the first > dot. > > Bug: > Webrev: > > Tested against GCC 10.0.0. configure no longer prints a C/C++ version > mismatch warning. Looks good. Tim From fweimer at redhat.com Mon Nov 11 07:53:02 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 11 Nov 2019 08:53:02 +0100 Subject: RFR 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <9d20aa41-86f6-9a27-4480-7f248addc5f4@oracle.com> (Tim Bell's message of "Sat, 9 Nov 2019 06:19:21 -0800") References: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> <9d20aa41-86f6-9a27-4480-7f248addc5f4@oracle.com> Message-ID: <8736euzw69.fsf@oldenburg2.str.redhat.com> * Tim Bell: > Florian: > >> The current regular expression only matches one digit before the first >> dot. >> >> Bug: >> Webrev: >> >> Tested against GCC 10.0.0. configure no longer prints a C/C++ version >> mismatch warning. > > Looks good. Would you please sponsor this change for me? Thanks. Florian From jorn.vernee at oracle.com Mon Nov 11 10:40:36 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 11 Nov 2019 11:40:36 +0100 Subject: RFR 8233844: Add LogCompilation build artifacts to .gitignore In-Reply-To: <70cacf73-9ff3-8cb3-c15b-22b126dea5de@oracle.com> References: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> <8236c9fa-2264-791b-42c3-b864ef72c765@oracle.com> <70cacf73-9ff3-8cb3-c15b-22b126dea5de@oracle.com> Message-ID: Ok, I think I've solved the mystery; Using some event tracing I found that some java.exe instance was running maven on this directory. Killing that process (it was running in the background) throws up an error in VSCode about the extension container going down. Seems that some VSCode extension is indiscriminately running maven on the LogCompilation project (which it's picking up). Time to start disabling some plugins :) Jorn On 08/11/2019 18:48, Jorn Vernee wrote: > Hello Erik, > > You are right, I spoke too soon. I deleted the artifacts and tried to > trigger the creation by doing a clean build and running some tests, > but neither seems to generate the artifacts. I'm really puzzled by > this, since I have 4 repos that contain these artifacts (both git and > hg), and I'm certain that I've never explicitly built this utility > using maven (I've never used it. I can imagine building it once and > not remembering, but not 4 times). > > Any way, here is the updated webrev: > http://cr.openjdk.java.net/~jvernee/8233844/webrev.02 > > I'll keep an eye out for these artifacts appearing again. > > Thanks, > Jorn > > On 08/11/2019 15:16, Erik Joelsson wrote: >> Hello Jorn, >> >> On 2019-11-08 04:24, Jorn Vernee wrote: >>> Hi, >>> >>> I'd like to contribute this very small patch that adds some >>> LogCompilation build artifacts to the .gitignore file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 >>> Webrev: >>> http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html >>> >>> Testing = manual >>> >>> FWIW, it seems that these artifacts are produced at some point >>> either while doing a vanilla build, or when running the test, so >>> these artifacts will show up pretty much always when using Git >>> (AFAICS I have them in all my OpenJDK Git repos, and I've never >>> directly used this utility). So, it seems worth it to gitnore them. >>> >> I've never seen these artifacts, and the only way I can see them >> being created is if you explicitly invoke the maven build for >> LogCompilation (which of course is a perfectly valid thing to do). >> The .classpath, .project and .settings files are eclipse project >> files and it could be argued that those should be put on ignore >> regardless of where in the source tree they are found, just like we >> already do for .idea. When adding this for .gitignore, I would prefer >> if we could keep parity with .hgignore so please add it there too. >> >> /Erik >> >>> As a heads-up; I'm not a committer on the JDK project, so a sponsor >>> would need to push this. >>> >>> Thanks, >>> Jorn >>> From suenaga at oss.nttdata.com Tue Nov 12 14:48:38 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 12 Nov 2019 23:48:38 +0900 Subject: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS Message-ID: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK with GCC 9.2.1 on Fedora 31. They are LCMS problems, thus we should avoid them to disable these warnings. This change has been tested on submit repo (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). Thanks, Yasumasa From dmitry.chuyko at bell-sw.com Tue Nov 12 16:41:26 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 12 Nov 2019 19:41:26 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> Message-ID: <3ad26b1b-bf99-59fa-a131-fea650a25bce@bell-sw.com> Hi Yasumasa, Thank you, looks good to me (not a reviewer though). Works with GCC 8.3. -Dmitry On 11/12/19 5:48 PM, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ > > I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK > with GCC 9.2.1 on Fedora 31. > They are LCMS problems, thus we should avoid them to disable these > warnings. > > This change has been tested on submit repo > (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). > > > Thanks, > > Yasumasa From philip.race at oracle.com Tue Nov 12 17:11:10 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Nov 2019 09:11:10 -0800 Subject: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> Message-ID: Was this ever reported upstream ? I'd like someone from build dev to comment on this, meaning the way the GCC version is detected and the separation of this into a separate block. We probably have some precedent & pattern for version specific warnings .. -phil. On 11/12/19 6:48 AM, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ > > I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK > with GCC 9.2.1 on Fedora 31. > They are LCMS problems, thus we should avoid them to disable these > warnings. > > This change has been tested on submit repo > (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). > > > Thanks, > > Yasumasa From erik.joelsson at oracle.com Tue Nov 12 17:47:52 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Nov 2019 09:47:52 -0800 Subject: RFR 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> References: <87d0e1z8wk.fsf@oldenburg2.str.redhat.com> Message-ID: <909b8992-b467-644d-b08c-7de4a47b5ebc@oracle.com> Looks good. /Erik On 2019-11-09 01:38, Florian Weimer wrote: > The current regular expression only matches one digit before the first > dot. > > Bug: > Webrev: > > Tested against GCC 10.0.0. configure no longer prints a C/C++ version > mismatch warning. > > Thanks, > Florian > From erik.joelsson at oracle.com Tue Nov 12 17:55:55 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Nov 2019 09:55:55 -0800 Subject: RFR 8233844: Add LogCompilation build artifacts to .gitignore In-Reply-To: <70cacf73-9ff3-8cb3-c15b-22b126dea5de@oracle.com> References: <2c29e4cd-3147-253f-5977-38d4e7598b60@oracle.com> <8236c9fa-2264-791b-42c3-b864ef72c765@oracle.com> <70cacf73-9ff3-8cb3-c15b-22b126dea5de@oracle.com> Message-ID: This looks good, thanks! /Erik On 2019-11-08 09:48, Jorn Vernee wrote: > Hello Erik, > > You are right, I spoke too soon. I deleted the artifacts and tried to > trigger the creation by doing a clean build and running some tests, > but neither seems to generate the artifacts. I'm really puzzled by > this, since I have 4 repos that contain these artifacts (both git and > hg), and I'm certain that I've never explicitly built this utility > using maven (I've never used it. I can imagine building it once and > not remembering, but not 4 times). > > Any way, here is the updated webrev: > http://cr.openjdk.java.net/~jvernee/8233844/webrev.02 > > I'll keep an eye out for these artifacts appearing again. > > Thanks, > Jorn > > On 08/11/2019 15:16, Erik Joelsson wrote: >> Hello Jorn, >> >> On 2019-11-08 04:24, Jorn Vernee wrote: >>> Hi, >>> >>> I'd like to contribute this very small patch that adds some >>> LogCompilation build artifacts to the .gitignore file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 >>> Webrev: >>> http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html >>> >>> Testing = manual >>> >>> FWIW, it seems that these artifacts are produced at some point >>> either while doing a vanilla build, or when running the test, so >>> these artifacts will show up pretty much always when using Git >>> (AFAICS I have them in all my OpenJDK Git repos, and I've never >>> directly used this utility). So, it seems worth it to gitnore them. >>> >> I've never seen these artifacts, and the only way I can see them >> being created is if you explicitly invoke the maven build for >> LogCompilation (which of course is a perfectly valid thing to do). >> The .classpath, .project and .settings files are eclipse project >> files and it could be argued that those should be put on ignore >> regardless of where in the source tree they are found, just like we >> already do for .idea. When adding this for .gitignore, I would prefer >> if we could keep parity with .hgignore so please add it there too. >> >> /Erik >> >>> As a heads-up; I'm not a committer on the JDK project, so a sponsor >>> would need to push this. >>> >>> Thanks, >>> Jorn >>> From erik.joelsson at oracle.com Tue Nov 12 18:04:02 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Nov 2019 10:04:02 -0800 Subject: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> Message-ID: <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> Hello, There is no need to do compiler version checks like this. We just add all the necessary warning disabling for all versions. GCC will not fail or warn for invalid -W-no... flags and we use this feature for this very reason. We don't think it's feasible to track warnings per compiler versions.. /Erik On 2019-11-12 06:48, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ > > I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK > with GCC 9.2.1 on Fedora 31. > They are LCMS problems, thus we should avoid them to disable these > warnings. > > This change has been tested on submit repo > (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). > > > Thanks, > > Yasumasa From suenaga at oss.nttdata.com Wed Nov 13 01:13:21 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 13 Nov 2019 10:13:21 +0900 Subject: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> Message-ID: On 2019/11/13 2:11, Phil Race wrote: > Was this ever reported upstream ? I heard Dmitry Chuyko has reported this issue to LCMS. > I'd like someone from build dev to comment on this, meaning > the way the GCC version is detected and the separation of this into a separate block. > We probably have some precedent & pattern for version specific warnings .. We can just add "stringop-truncation" to DISABLED_WARNINGS_gcc in Makefile as Erik said. I pushed new change to submit repo. I will send review request when it passed. http://hg.openjdk.java.net/jdk/submit/rev/7899a3b10450 Thanks, Yasumasa > -phil. > > On 11/12/19 6:48 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >> >> I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK with GCC 9.2.1 on Fedora 31. >> They are LCMS problems, thus we should avoid them to disable these warnings. >> >> This change has been tested on submit repo (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >> >> >> Thanks, >> >> Yasumasa > From suenaga at oss.nttdata.com Wed Nov 13 02:42:14 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 13 Nov 2019 11:42:14 +0900 Subject: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> Message-ID: <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> Thanks Erik! I uploaded new webrev, and it passed all tests on submit repo (mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052). http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ Yasumasa On 2019/11/13 3:04, Erik Joelsson wrote: > Hello, > > There is no need to do compiler version checks like this. We just add all the necessary warning disabling for all versions. GCC will not fail or warn for invalid -W-no... flags and we use this feature for this very reason. We don't think it's feasible to track warnings per compiler versions.. > > /Erik > > On 2019-11-12 06:48, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >> >> I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK with GCC 9.2.1 on Fedora 31. >> They are LCMS problems, thus we should avoid them to disable these warnings. >> >> This change has been tested on submit repo (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >> >> >> Thanks, >> >> Yasumasa From johan.vos at gluonhq.com Thu Nov 14 08:50:48 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 14 Nov 2019 09:50:48 +0100 Subject: cross compiling with different toolchain type Message-ID: Hi, I just want to make sure there is still a limitation in place where the toolchain type of a cross compiler must equal the toolchain type of the build compiler? I'm configuring a build for Android (aarch64-linux) and I am using the clang toolchain type for doing the cross compilation, while I'm using gcc as the build compiler. However, I get errors running configure: configure: The BuildC compiler (located as /usr/bin/cc) does not seem to be the required clang compiler. Looking into toolchain.m4, this sounds fair to me, as the BuildC compiler (line 916 and below) is also tested with TOOLCHAIN_EXTRACT_COMPILER_VERSION(BUILD_CC, [BuildC]) which unconditionally checks for the $TOOLCHAIN_TYPE. Hence, it seems cross-compiling using a clang compiler, while using gcc as the build compiler is not possible. That's by no means a showstopper to me, I just want to double check that I'm not missing something. Thanks, - Johan From erik.joelsson at oracle.com Thu Nov 14 16:27:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Nov 2019 08:27:19 -0800 Subject: cross compiling with different toolchain type In-Reply-To: References: Message-ID: <803e14e0-c98e-8d0d-6411-8f1dee53daff@oracle.com> Hello Johan, You are correct, this limitation is still present. There is no good reason for this other than we never having needed to put effort into fixing it. It could help if you build a native JDK first and then configure your cross build with --with-build-jdk= pointing to your native JDK, but I suspect this particular configure check will still fail. /Erik On 2019-11-14 00:50, Johan Vos wrote: > Hi, > > I just want to make sure there is still a limitation in place where the > toolchain type of a cross compiler must equal the toolchain type of the > build compiler? > I'm configuring a build for Android (aarch64-linux) and I am using the > clang toolchain type for doing the cross compilation, while I'm using gcc > as the build compiler. However, I get errors running configure: > > configure: The BuildC compiler (located as /usr/bin/cc) does not seem to be > the required clang compiler. > > Looking into toolchain.m4, this sounds fair to me, as the BuildC compiler > (line 916 and below) is also tested > with TOOLCHAIN_EXTRACT_COMPILER_VERSION(BUILD_CC, [BuildC]) which > unconditionally checks for the $TOOLCHAIN_TYPE. > > Hence, it seems cross-compiling using a clang compiler, while using gcc as > the build compiler is not possible. > That's by no means a showstopper to me, I just want to double check that > I'm not missing something. > > Thanks, > > - Johan From sgehwolf at redhat.com Fri Nov 15 12:23:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Nov 2019 13:23:28 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <06d84de7-b05e-a4a2-7a01-e604cd1f7c7e@oracle.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> <06d84de7-b05e-a4a2-7a01-e604cd1f7c7e@oracle.com> Message-ID: Hi Erik, Magnus, On Fri, 2019-11-08 at 08:57 -0800, Erik Joelsson wrote: > Hello Severin, > > On 2019-11-08 07:48, Severin Gehwolf wrote: > > Right. I believe webrev 03 does this? > Yes, that was mostly a reply to Magnus. > > Thanks! Tried it, which doesn't seem to work[1]: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/04/webrev/ > > Looking at your job, it's failing already in configure on our Linux > hosts. At least on Oracle Linux, it seems ulimit is a bash builtin and > not found in path. Configure needs to fallback on that. Thanks for the info. This updated webrev passes jdk/submit now: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/05/webrev/ Thoughts? Thanks, Severin > > Is there some way to reproduce locally? > > > > Thanks, > > Severin > > > > [1] [Mach5] mach5-one-sgehwolf-JDK-8233712-4-20191108-1454-6533841: > > FAILED > > > > > /Erik > > > > > > > Thanks, > > > > Severin > > > > From daniel.daugherty at oracle.com Fri Nov 15 15:08:47 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Nov 2019 10:08:47 -0500 Subject: RFR(M): 8233787: Break cycle in vm_version* includes In-Reply-To: References: <52D7C0FA-BDAE-43D6-9607-2F4FAA58524A@sap.com> <9BDEBE4D-DA1F-4087-937A-56ADA1E1F7A5@oracle.com> Message-ID: Adding build-dev at ... since this changeset now touches make/hotspot/lib/CompileJvm.gmk. The Build team has a standing request to be included on reviews that touch makefiles... Dan On 11/14/19 11:26 AM, Schmidt, Lutz wrote: > Hi Kim, > > that wasn't straightforward. Had to adapt make/hotspot/lib/CompileJvm.gmk. Build settings like HOTSPOT_VERSION_STRING have to flow into the compile step of abstract_vm_version.cpp now. For the details, see my comments below. > > Other than that, I hope the new webrev is even closer to your dreams: > http://cr.openjdk.java.net/~lucy/webrevs/8233787.02/ > > Thanks, > Lutz > > > ?On 14.11.19, 00:34, "Kim Barrett" wrote: > > > On Nov 13, 2019, at 11:42 AM, Schmidt, Lutz wrote: > > > > Hi Kim, > > > > there is a new webrev at http://cr.openjdk.java.net/~lucy/webrevs/8233787.01/ > > > > It should be pretty close to what you view as the "right approach". There weren't too many changes relative to 8233787.00. Most files already had #include runtime/vm_version.hpp. > > This looks much better to me, but many (most?) of the changed > #includes need to be moved into sort order. > > R: tried my best to fix the sort order. Sorry for not paying attention in the first place. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/vm_version.cpp > > Abstract_VM_Version definitions should be moved to abstract_vm_version.cpp. > Maybe just rename the file; I think the only thing that would be left > for vm_version.cpp would be VM_Version_init(). But maybe that should > be left behind in vm_version.cpp? Though that makes the review messier. > > R: Everything moved as you suggested. Doesn't make sense to have Abstract_VM_Version:: methods in vm_version.cpp file. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/abstract_vm_version.hpp > > Should #include globalDefinitions.hpp. > - uint64_t features() > - #define SUPPORTS_NATIVE_CX8 > > R: Done. > > Should forward-declare class outsputStream. > - print_virtualization_info > - print_matching_lines_from_file (I wonder why this is *here*, but not your problem) > > R: Done. > > ------------------------------------------------------------------------------ > > > > From erik.joelsson at oracle.com Fri Nov 15 16:27:27 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Nov 2019 08:27:27 -0800 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> <06d84de7-b05e-a4a2-7a01-e604cd1f7c7e@oracle.com> Message-ID: <35d91d5a-becc-fc9c-d96b-04d5eb268392@oracle.com> On 2019-11-15 04:23, Severin Gehwolf wrote: > Hi Erik, Magnus, > > On Fri, 2019-11-08 at 08:57 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> On 2019-11-08 07:48, Severin Gehwolf wrote: >>> Right. I believe webrev 03 does this? >> Yes, that was mostly a reply to Magnus. >>> Thanks! Tried it, which doesn't seem to work[1]: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/04/webrev/ >> Looking at your job, it's failing already in configure on our Linux >> hosts. At least on Oracle Linux, it seems ulimit is a bash builtin and >> not found in path. Configure needs to fallback on that. > Thanks for the info. This updated webrev passes jdk/submit now: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/05/webrev/ > > Thoughts? That is an interesting approach. I think it's good to go. Magnus may want to tweak it, but as he is on vacation, it may take a while to get feedback from him. Perhaps we could just put the builtin logic in the default BASIC_REQUIRE_PROG, but we could also wait and do that later. No need to stall this fix more I think. /Erik > Thanks, > Severin > >>> Is there some way to reproduce locally? >>> >>> Thanks, >>> Severin >>> >>> [1] [Mach5] mach5-one-sgehwolf-JDK-8233712-4-20191108-1454-6533841: >>> FAILED >>> >>>> /Erik >>>> >>>>> Thanks, >>>>> Severin >>>>> From sgehwolf at redhat.com Fri Nov 15 16:31:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Nov 2019 17:31:51 +0100 Subject: RFR: 8233712: Limit default tests jobs based on ulimit -u setting In-Reply-To: <35d91d5a-becc-fc9c-d96b-04d5eb268392@oracle.com> References: <438ef46ecfe5878778fd2aaee84eee57753cce10.camel@redhat.com> <9989496b-8741-6bce-dfa6-9e7c7be9563e@oracle.com> <2f93a000f22c386ea430389dc6c21de24dc6ea9c.camel@redhat.com> <3dca0303-dfd2-7cd8-b0d5-54192adfcb94@oracle.com> <35125f8f9a07db96a968cc3e15493f90c98dae6d.camel@redhat.com> <98b4b2293348b02df5fe1a49b53d5acbfbb0d327.camel@redhat.com> <06d84de7-b05e-a4a2-7a01-e604cd1f7c7e@oracle.com> <35d91d5a-becc-fc9c-d96b-04d5eb268392@oracle.com> Message-ID: On Fri, 2019-11-15 at 08:27 -0800, Erik Joelsson wrote: > On 2019-11-15 04:23, Severin Gehwolf wrote: > > Hi Erik, Magnus, > > > > On Fri, 2019-11-08 at 08:57 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > On 2019-11-08 07:48, Severin Gehwolf wrote: > > > > Right. I believe webrev 03 does this? > > > Yes, that was mostly a reply to Magnus. > > > > Thanks! Tried it, which doesn't seem to work[1]: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/04/webrev/ > > > Looking at your job, it's failing already in configure on our Linux > > > hosts. At least on Oracle Linux, it seems ulimit is a bash builtin and > > > not found in path. Configure needs to fallback on that. > > Thanks for the info. This updated webrev passes jdk/submit now: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233712/05/webrev/ > > > > Thoughts? > > That is an interesting approach. I think it's good to go. Magnus may > want to tweak it, but as he is on vacation, it may take a while to get > feedback from him. I see. > Perhaps we could just put the builtin logic in the default > BASIC_REQUIRE_PROG, but we could also wait and do that later. No need to > stall this fix more I think. Thanks, Erik. I'll get this pushed on Monday if I hear no objections by then. Cheers, Severin > /Erik > > > Thanks, > > Severin > > > > > > Is there some way to reproduce locally? > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] [Mach5] mach5-one-sgehwolf-JDK-8233712-4-20191108-1454-6533841: > > > > FAILED > > > > > > > > > /Erik > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > From erik.joelsson at oracle.com Fri Nov 15 16:31:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Nov 2019 08:31:57 -0800 Subject: RFR(M): 8233787: Break cycle in vm_version* includes In-Reply-To: References: <52D7C0FA-BDAE-43D6-9607-2F4FAA58524A@sap.com> <9BDEBE4D-DA1F-4087-937A-56ADA1E1F7A5@oracle.com> Message-ID: <47239af1-1d8a-e313-bda1-c62785fe9058@oracle.com> Build change looks ok. /Erik On 2019-11-15 07:08, Daniel D. Daugherty wrote: > Adding build-dev at ... since this changeset now touches > make/hotspot/lib/CompileJvm.gmk. The Build team has a standing > request to be included on reviews that touch makefiles... > > Dan > > > On 11/14/19 11:26 AM, Schmidt, Lutz wrote: >> Hi Kim, >> >> that wasn't straightforward. Had to adapt >> make/hotspot/lib/CompileJvm.gmk. Build settings like >> HOTSPOT_VERSION_STRING have to flow into the compile step of >> abstract_vm_version.cpp now. For the details, see my comments below. >> >> Other than that, I hope the new webrev is even closer to your dreams: >> ??? http://cr.openjdk.java.net/~lucy/webrevs/8233787.02/ >> >> Thanks, >> Lutz >> >> >> ?On 14.11.19, 00:34, "Kim Barrett" wrote: >> >> ???? > On Nov 13, 2019, at 11:42 AM, Schmidt, Lutz >> wrote: >> ???? > >> ???? > Hi Kim, >> ???? > >> ???? > there is a new webrev at >> http://cr.openjdk.java.net/~lucy/webrevs/8233787.01/ >> ???? > >> ???? > It should be pretty close to what you view as the "right >> approach". There weren't too many changes relative to 8233787.00. >> Most files already had #include runtime/vm_version.hpp. >> ???? ???? This looks much better to me, but many (most?) of the changed >> ???? #includes need to be moved into sort order. >> >> R: tried my best to fix the sort order. Sorry for not paying >> attention in the first place. >> ------------------------------------------------------------------------------ >> ???? src/hotspot/share/runtime/vm_version.cpp >> ???? ???? Abstract_VM_Version definitions should be moved to >> abstract_vm_version.cpp. >> ???? Maybe just rename the file; I think the only thing that would be >> left >> ???? for vm_version.cpp would be VM_Version_init().? But maybe that >> should >> ???? be left behind in vm_version.cpp?? Though that makes the review >> messier. >> >> R: Everything moved as you suggested. Doesn't make sense to have >> Abstract_VM_Version:: methods in vm_version.cpp file. >> ------------------------------------------------------------------------------ >> ???? src/hotspot/share/runtime/abstract_vm_version.hpp >> ???? ???? Should #include globalDefinitions.hpp. >> ???? - uint64_t features() >> ???? - #define SUPPORTS_NATIVE_CX8 >> >> R: Done. >> ???? ???? Should forward-declare class outsputStream. >> ???? - print_virtualization_info >> ???? - print_matching_lines_from_file (I wonder why this is *here*, >> but not your problem) >> >> R: Done. >> ------------------------------------------------------------------------------ >> > From lutz.schmidt at sap.com Fri Nov 15 21:50:04 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 15 Nov 2019 21:50:04 +0000 Subject: RFR(M): 8233787: Break cycle in vm_version* includes In-Reply-To: <47239af1-1d8a-e313-bda1-c62785fe9058@oracle.com> References: <52D7C0FA-BDAE-43D6-9607-2F4FAA58524A@sap.com> <9BDEBE4D-DA1F-4087-937A-56ADA1E1F7A5@oracle.com> <47239af1-1d8a-e313-bda1-c62785fe9058@oracle.com> Message-ID: Thank you, Erik, for confirming the build change. And sorry for not including you immediately. Regards, Lutz P.S.: And thanks, Daniel, for including the build team. ?On 15.11.19, 17:31, "Erik Joelsson" wrote: Build change looks ok. /Erik On 2019-11-15 07:08, Daniel D. Daugherty wrote: > Adding build-dev at ... since this changeset now touches > make/hotspot/lib/CompileJvm.gmk. The Build team has a standing > request to be included on reviews that touch makefiles... > > Dan > > > On 11/14/19 11:26 AM, Schmidt, Lutz wrote: >> Hi Kim, >> >> that wasn't straightforward. Had to adapt >> make/hotspot/lib/CompileJvm.gmk. Build settings like >> HOTSPOT_VERSION_STRING have to flow into the compile step of >> abstract_vm_version.cpp now. For the details, see my comments below. >> >> Other than that, I hope the new webrev is even closer to your dreams: >> http://cr.openjdk.java.net/~lucy/webrevs/8233787.02/ >> >> Thanks, >> Lutz >> >> >> On 14.11.19, 00:34, "Kim Barrett" wrote: >> >> > On Nov 13, 2019, at 11:42 AM, Schmidt, Lutz >> wrote: >> > >> > Hi Kim, >> > >> > there is a new webrev at >> http://cr.openjdk.java.net/~lucy/webrevs/8233787.01/ >> > >> > It should be pretty close to what you view as the "right >> approach". There weren't too many changes relative to 8233787.00. >> Most files already had #include runtime/vm_version.hpp. >> This looks much better to me, but many (most?) of the changed >> #includes need to be moved into sort order. >> >> R: tried my best to fix the sort order. Sorry for not paying >> attention in the first place. >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/vm_version.cpp >> Abstract_VM_Version definitions should be moved to >> abstract_vm_version.cpp. >> Maybe just rename the file; I think the only thing that would be >> left >> for vm_version.cpp would be VM_Version_init(). But maybe that >> should >> be left behind in vm_version.cpp? Though that makes the review >> messier. >> >> R: Everything moved as you suggested. Doesn't make sense to have >> Abstract_VM_Version:: methods in vm_version.cpp file. >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/abstract_vm_version.hpp >> Should #include globalDefinitions.hpp. >> - uint64_t features() >> - #define SUPPORTS_NATIVE_CX8 >> >> R: Done. >> Should forward-declare class outsputStream. >> - print_virtualization_info >> - print_matching_lines_from_file (I wonder why this is *here*, >> but not your problem) >> >> R: Done. >> ------------------------------------------------------------------------------ >> > From aleksei.voitylov at bell-sw.com Mon Nov 18 13:10:22 2019 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 18 Nov 2019 16:10:22 +0300 Subject: RFR(S): 8231612: 100% cpu on arm32 in Service Thread Message-ID: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> Hi, please review this build-only workaround for a GCC bug [1]. The problem surfaced on ARM32 when new code [2] got inlined with old code. In GCC at RTL level there is no good distinction between pointer and int, which makes it hard for the aliasing code to correctly recognize base addresses for objects, which leads to incorrect aliasing. As a consequence one of the loads in this code was completely eliminated on ARM32 by DSE. All GCC versions I could reach are affected. Thanks to the GCC community, the fix will appear in GCC 10 but before it becomes mainstream we need a workaround. The workaround is to disable -ftree-pre optimization on ARM32 which triggers the bug. The problem does not surface on x86 in this code. issue: https://bugs.openjdk.java.net/browse/JDK-8231612 webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8231612.02/ Testing on ARM32: the problem described in?8231612 (100% CPU utilization in Service Thread) no longer appears, the load is not eliminated as observed by disassembly. Testing on x86_64: linux-x86_64-server-release builds OK after this change. Thanks, -Aleksei [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 [2] https://bugs.openjdk.java.net/browse/JDK-8226366 From erik.joelsson at oracle.com Mon Nov 18 15:15:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Nov 2019 07:15:44 -0800 Subject: RFR(S): 8231612: 100% cpu on arm32 in Service Thread In-Reply-To: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> References: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> Message-ID: Looks good! /Erik On 2019-11-18 05:10, Aleksei Voitylov wrote: > Hi, > > please review this build-only workaround for a GCC bug [1]. The problem > surfaced on ARM32 when new code [2] got inlined with old code. In GCC at > RTL level there is no good distinction between pointer and int, which > makes it hard for the aliasing code to correctly recognize base > addresses for objects, which leads to incorrect aliasing. As a > consequence one of the loads in this code was completely eliminated on > ARM32 by DSE. All GCC versions I could reach are affected. > > Thanks to the GCC community, the fix will appear in GCC 10 but before it > becomes mainstream we need a workaround. The workaround is to disable > -ftree-pre optimization on ARM32 which triggers the bug. The problem > does not surface on x86 in this code. > > issue: https://bugs.openjdk.java.net/browse/JDK-8231612 > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8231612.02/ > > Testing on ARM32: the problem described in?8231612 (100% CPU utilization > in Service Thread) no longer appears, the load is not eliminated as > observed by disassembly. > Testing on x86_64: linux-x86_64-server-release builds OK after this change. > > Thanks, > > -Aleksei > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 > [2] https://bugs.openjdk.java.net/browse/JDK-8226366 > > From kim.barrett at oracle.com Mon Nov 18 22:51:12 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Nov 2019 17:51:12 -0500 Subject: RFR(S): 8231612: 100% cpu on arm32 in Service Thread In-Reply-To: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> References: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> Message-ID: > On Nov 18, 2019, at 8:10 AM, Aleksei Voitylov wrote: > > Hi, > > please review this build-only workaround for a GCC bug [1]. The problem > surfaced on ARM32 when new code [2] got inlined with old code. In GCC at > RTL level there is no good distinction between pointer and int, which > makes it hard for the aliasing code to correctly recognize base > addresses for objects, which leads to incorrect aliasing. As a > consequence one of the loads in this code was completely eliminated on > ARM32 by DSE. All GCC versions I could reach are affected. > > Thanks to the GCC community, the fix will appear in GCC 10 but before it > becomes mainstream we need a workaround. The workaround is to disable > -ftree-pre optimization on ARM32 which triggers the bug. The problem > does not surface on x86 in this code. > > issue: https://bugs.openjdk.java.net/browse/JDK-8231612 > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8231612.02/ > > Testing on ARM32: the problem described in 8231612 (100% CPU utilization > in Service Thread) no longer appears, the load is not eliminated as > observed by disassembly. > Testing on x86_64: linux-x86_64-server-release builds OK after this change. > > Thanks, > > -Aleksei > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 > [2] https://bugs.openjdk.java.net/browse/JDK-8226366 This change to limit the optimization of OopStorage.cpp doesn't seem sufficient to me, based on my reading the gcc bug thread. From that thread it sounds like any use of our CmpxchgByteUsingInt helper may be miscompiled. (And who knows what else...) There are certainly other uses of that helper. On that platform I think it gets used for any Atomic::cmpxchg of a bool value; at least, that's where I *think* OopStorage is hitting it. (I'm guessing the problem is the cmpxchg in has_cleanup_work_and_reset.) Just egrepping for "cmpxchg\((true|false)" finds ./share/gc/g1/g1RemSet.cpp: bool marked_as_dirty = Atomic::cmpxchg(true, &_contains[region], false) == false; ./share/gc/g1/g1RemSet.cpp: return !Atomic::cmpxchg(true, &_collection_set_iter_state[region], false); ./share/gc/g1/g1RemSet.cpp: !Atomic::cmpxchg(true, &_fast_reclaim_handled, false)) { ./share/gc/z/zRootsIterator.cpp: if (!_claimed && Atomic::cmpxchg(true, &_claimed, false) == false) { ./share/gc/z/zRootsIterator.cpp: if (!_claimed && Atomic::cmpxchg(true, &_claimed, false) == false) { ./share/gc/shared/oopStorage.cpp: return Atomic::cmpxchg(false, &needs_cleanup_requested, true); ./share/gc/shared/ptrQueue.cpp: Atomic::cmpxchg(true, &_transfer_lock, false)) { ./share/services/memTracker.cpp: if (Atomic::cmpxchg(true, &g_final_report_did_run, false) == false) { There may be others with non-literal new-value arguments. And there may be non-bool byte-sized cmpxchg's, though I don't offhand know of any. The two in zRootsIterator don't matter for arm32 (ZGC isn't supported on 32bit platforms), but is this problem limited to arm32? The gcc bug thread suggests it isn't affecting x86_32/64, and might be limited to arm(32?). Also, the latest comment in the gcc thread says the proposed fix doesn't work, so maybe not (yet) fixed in gcc 10. From mikael.vidstedt at oracle.com Mon Nov 18 23:28:08 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 18 Nov 2019 15:28:08 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports Message-ID: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> Please review this change which implements the changes for JEP 362: Deprecate the Solaris and SPARC Ports. JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ I?ve tested that the expected error message is produced by default, and that running with --enable-deprecated-ports=yes produces a warning instead. Cheers, Mikael From suenaga at oss.nttdata.com Tue Nov 19 01:34:51 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 19 Nov 2019 10:34:51 +0900 Subject: PING: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> Message-ID: <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> PING: Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ I think it is a trivial change. Yasumasa On 2019/11/13 11:42, Yasumasa Suenaga wrote: > Thanks Erik! > > I uploaded new webrev, and it passed all tests on submit repo (mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052). > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ > > Yasumasa > > > On 2019/11/13 3:04, Erik Joelsson wrote: >> Hello, >> >> There is no need to do compiler version checks like this. We just add all the necessary warning disabling for all versions. GCC will not fail or warn for invalid -W-no... flags and we use this feature for this very reason. We don't think it's feasible to track warnings per compiler versions.. >> >> /Erik >> >> On 2019-11-12 06:48, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >>> >>> I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK with GCC 9.2.1 on Fedora 31. >>> They are LCMS problems, thus we should avoid them to disable these warnings. >>> >>> This change has been tested on submit repo (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >>> >>> >>> Thanks, >>> >>> Yasumasa From philip.race at oracle.com Tue Nov 19 02:43:42 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 18 Nov 2019 18:43:42 -0800 Subject: [OpenJDK 2D-Dev] PING: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> Message-ID: <5DD356DE.4040100@oracle.com> OK -phil. On 11/18/19, 5:34 PM, Yasumasa Suenaga wrote: > PING: Could you review it? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ > > I think it is a trivial change. > > > Yasumasa > > > On 2019/11/13 11:42, Yasumasa Suenaga wrote: >> Thanks Erik! >> >> I uploaded new webrev, and it passed all tests on submit repo >> (mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052). >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ >> >> Yasumasa >> >> >> On 2019/11/13 3:04, Erik Joelsson wrote: >>> Hello, >>> >>> There is no need to do compiler version checks like this. We just >>> add all the necessary warning disabling for all versions. GCC will >>> not fail or warn for invalid -W-no... flags and we use this feature >>> for this very reason. We don't think it's feasible to track warnings >>> per compiler versions.. >>> >>> /Erik >>> >>> On 2019-11-12 06:48, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >>>> >>>> I saw some -Wstringop-truncation warnings in LCMS when I build >>>> OpenJDK with GCC 9.2.1 on Fedora 31. >>>> They are LCMS problems, thus we should avoid them to disable these >>>> warnings. >>>> >>>> This change has been tested on submit repo >>>> (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From suenaga at oss.nttdata.com Tue Nov 19 04:24:57 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 19 Nov 2019 13:24:57 +0900 Subject: [OpenJDK 2D-Dev] PING: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <5DD356DE.4040100@oracle.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> <5DD356DE.4040100@oracle.com> Message-ID: <4db949f0-b79c-dcb9-d16b-aba64eec18a6@oss.nttdata.com> Thanks Phil! Yasumasa On 2019/11/19 11:43, Philip Race wrote: > > OK > > -phil. > > On 11/18/19, 5:34 PM, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ >> >> I think it is a trivial change. >> >> >> Yasumasa >> >> >> On 2019/11/13 11:42, Yasumasa Suenaga wrote: >>> Thanks Erik! >>> >>> I uploaded new webrev, and it passed all tests on submit repo (mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052). >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ >>> >>> Yasumasa >>> >>> >>> On 2019/11/13 3:04, Erik Joelsson wrote: >>>> Hello, >>>> >>>> There is no need to do compiler version checks like this. We just add all the necessary warning disabling for all versions. GCC will not fail or warn for invalid -W-no... flags and we use this feature for this very reason. We don't think it's feasible to track warnings per compiler versions.. >>>> >>>> /Erik >>>> >>>> On 2019-11-12 06:48, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >>>>> >>>>> I saw some -Wstringop-truncation warnings in LCMS when I build OpenJDK with GCC 9.2.1 on Fedora 31. >>>>> They are LCMS problems, thus we should avoid them to disable these warnings. >>>>> >>>>> This change has been tested on submit repo (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa From aleksei.voitylov at bell-sw.com Tue Nov 19 15:18:01 2019 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 19 Nov 2019 18:18:01 +0300 Subject: RFR(S): 8231612: 100% cpu on arm32 in Service Thread In-Reply-To: References: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> Message-ID: Kim, you are right, to play it safe we need to -fno-tree-pre all relevant bool occurrances. I'll get back with an updated webrev when testing is finished. -Aleksei On 19/11/2019 01:51, Kim Barrett wrote: >> On Nov 18, 2019, at 8:10 AM, Aleksei Voitylov wrote: >> >> Hi, >> >> please review this build-only workaround for a GCC bug [1]. The problem >> surfaced on ARM32 when new code [2] got inlined with old code. In GCC at >> RTL level there is no good distinction between pointer and int, which >> makes it hard for the aliasing code to correctly recognize base >> addresses for objects, which leads to incorrect aliasing. As a >> consequence one of the loads in this code was completely eliminated on >> ARM32 by DSE. All GCC versions I could reach are affected. >> >> Thanks to the GCC community, the fix will appear in GCC 10 but before it >> becomes mainstream we need a workaround. The workaround is to disable >> -ftree-pre optimization on ARM32 which triggers the bug. The problem >> does not surface on x86 in this code. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8231612 >> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8231612.02/ >> >> Testing on ARM32: the problem described in 8231612 (100% CPU utilization >> in Service Thread) no longer appears, the load is not eliminated as >> observed by disassembly. >> Testing on x86_64: linux-x86_64-server-release builds OK after this change. >> >> Thanks, >> >> -Aleksei >> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 >> [2] https://bugs.openjdk.java.net/browse/JDK-8226366 > This change to limit the optimization of OopStorage.cpp doesn't seem > sufficient to me, based on my reading the gcc bug thread. From that > thread it sounds like any use of our CmpxchgByteUsingInt helper may be > miscompiled. (And who knows what else...) > > There are certainly other uses of that helper. On that platform I > think it gets used for any Atomic::cmpxchg of a bool value; at least, > that's where I *think* OopStorage is hitting it. (I'm guessing the > problem is the cmpxchg in has_cleanup_work_and_reset.) > > Just egrepping for "cmpxchg\((true|false)" finds > > ./share/gc/g1/g1RemSet.cpp: bool marked_as_dirty = Atomic::cmpxchg(true, &_contains[region], false) == false; > ./share/gc/g1/g1RemSet.cpp: return !Atomic::cmpxchg(true, &_collection_set_iter_state[region], false); > ./share/gc/g1/g1RemSet.cpp: !Atomic::cmpxchg(true, &_fast_reclaim_handled, false)) { > ./share/gc/z/zRootsIterator.cpp: if (!_claimed && Atomic::cmpxchg(true, &_claimed, false) == false) { > ./share/gc/z/zRootsIterator.cpp: if (!_claimed && Atomic::cmpxchg(true, &_claimed, false) == false) { > ./share/gc/shared/oopStorage.cpp: return Atomic::cmpxchg(false, &needs_cleanup_requested, true); > ./share/gc/shared/ptrQueue.cpp: Atomic::cmpxchg(true, &_transfer_lock, false)) { > ./share/services/memTracker.cpp: if (Atomic::cmpxchg(true, &g_final_report_did_run, false) == false) { > > There may be others with non-literal new-value arguments. And there > may be non-bool byte-sized cmpxchg's, though I don't offhand know of any. > > The two in zRootsIterator don't matter for arm32 (ZGC isn't supported > on 32bit platforms), but is this problem limited to arm32? The gcc > bug thread suggests it isn't affecting x86_32/64, and might be limited > to arm(32?). > > Also, the latest comment in the gcc thread says the proposed fix > doesn't work, so maybe not (yet) fixed in gcc 10. > > From kim.barrett at oracle.com Tue Nov 19 16:01:11 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Nov 2019 11:01:11 -0500 Subject: RFR(S): 8231612: 100% cpu on arm32 in Service Thread In-Reply-To: References: <6bb696c5-137c-e847-50f9-af18b7a8ed50@bell-sw.com> Message-ID: <64E92E6D-066C-4AFA-A6BB-CC7500F0C7C6@oracle.com> > On Nov 19, 2019, at 10:18 AM, Aleksei Voitylov wrote: > > Kim, > > you are right, to play it safe we need to -fno-tree-pre all relevant > bool occurrances. I'll get back with an updated webrev when testing is > finished. I think just sprinkling the build system with -fno-tree-pre to address this doesn?t scale in the face of people writing new code. I think we need to find a way to write CmpxchgByteUsingInt in such a way that it doesn?t tickle this bug, or forbid byte-sized cmpxchg (which would be painful), or provide some entirely other implementation approach. From erik.joelsson at oracle.com Wed Nov 20 15:47:12 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Nov 2019 07:47:12 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> Message-ID: <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> Looks good. /Erik On 2019-11-18 15:28, Mikael Vidstedt wrote: > Please review this change which implements the changes for JEP 362: Deprecate the Solaris and SPARC Ports. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ > > I?ve tested that the expected error message is produced by default, and that running with --enable-deprecated-ports=yes produces a warning instead. > > Cheers, > Mikael > From erik.joelsson at oracle.com Wed Nov 20 15:48:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Nov 2019 07:48:04 -0800 Subject: PING: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS In-Reply-To: <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> References: <461e6d46-f5ff-6e24-28c4-ad3226f37a0b@oss.nttdata.com> <5572cdf9-c615-fd5d-aab0-16b61b3ba901@oracle.com> <0b877d7b-9dfd-867e-e89d-078eb0182698@oss.nttdata.com> <1327c3ba-06c2-42b7-cb67-26c31644dcf4@oss.nttdata.com> Message-ID: <8e5b64d2-435b-f4c1-7222-918f634c5565@oracle.com> Looks good. /Erik On 2019-11-18 17:34, Yasumasa Suenaga wrote: > PING: Could you review it? > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ > > I think it is a trivial change. > > > Yasumasa > > > On 2019/11/13 11:42, Yasumasa Suenaga wrote: >> Thanks Erik! >> >> I uploaded new webrev, and it passed all tests on submit repo >> (mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052). >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ >> >> Yasumasa >> >> >> On 2019/11/13 3:04, Erik Joelsson wrote: >>> Hello, >>> >>> There is no need to do compiler version checks like this. We just >>> add all the necessary warning disabling for all versions. GCC will >>> not fail or warn for invalid -W-no... flags and we use this feature >>> for this very reason. We don't think it's feasible to track warnings >>> per compiler versions.. >>> >>> /Erik >>> >>> On 2019-11-12 06:48, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/ >>>> >>>> I saw some -Wstringop-truncation warnings in LCMS when I build >>>> OpenJDK with GCC 9.2.1 on Fedora 31. >>>> They are LCMS problems, thus we should avoid them to disable these >>>> warnings. >>>> >>>> This change has been tested on submit repo >>>> (mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576). >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From christoph.goettschkes at microdoc.com Wed Nov 20 18:22:13 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Wed, 20 Nov 2019 19:22:13 +0100 Subject: RFR: 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC Message-ID: Hi, please review the following change. Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev.00/ The removed lines are completely out of place and have no use at all. for the CC variable, for instance, the script does the following: CC_OLD="$CC" CC="$BUILD_CC" CC="$CC_OLD" without executing any function between those lines. I think that, while restructuring the build system, those lines have been copied to the wrong location. I copied them around the "FLAGS_SETUP_CFLAGS_CPU_DEP" call for the BUILD_CC, in order to make configure not use the target CFLAGS while discovering possible CFLAGS for the BUILD_CC, which was happening in our case. I am also not sure if the variable BUILD_CC_DISABLE_WARNING_PREFIX is actually used anywhere. I could not find any user and it might be possible to simply remove it. I tried the change and compiled on an amd64 linux machine for amd64, and cross-compiled for linux on armv7 and linux on aarch64. I don't have access to other cross-compilation environments and would like to ask others to review and try out the change. Thanks, Christoph From mikael.vidstedt at oracle.com Wed Nov 20 20:03:50 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 20 Nov 2019 12:03:50 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> Message-ID: I noticed that most of the configure options include the default value in the help string (in brackets), so here?s an updated webrev which does exactly that: Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01/open/webrev Webrev (incremental): http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01.incr/open/webrev/ Cheers, Mikael > On Nov 20, 2019, at 7:47 AM, Erik Joelsson wrote: > > Looks good. > > /Erik > > On 2019-11-18 15:28, Mikael Vidstedt wrote: >> Please review this change which implements the changes for JEP 362: Deprecate the Solaris and SPARC Ports. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ >> >> I?ve tested that the expected error message is produced by default, and that running with --enable-deprecated-ports=yes produces a warning instead. >> >> Cheers, >> Mikael >> From matthias.baesken at sap.com Thu Nov 21 08:54:39 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Nov 2019 08:54:39 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code Message-ID: Hello, gcc and ld can be instructed to work together to "garbage collect" unused input sections. This feature eliminates unused code from native libraries. As a prerequisite to take full advantage of the feature, the source files need to be compiled with "-ffunction-sections -fdata-sections". Details on what happens can be found in the ld documentation: https://linux.die.net/man/1/ld . See the description of --gc-sections and --print-gc-sections therein. For more detailed insights there is a talk available from ELC2010: https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf My change enables the unused code elimination on linux s390x . (on the other Linux platforms, there are still issues to be solved with the serviceability agent, but we do not have the serviceability agent on linux s390x). The change has 2 benefits : - native libs with unused code get smaller (some get alot smaller) some example lib sizes from linuxs390x (product build) : default settings / link-time gc-sections libmlib_image.so 556K 536K libjavajpeg.so 300K 292K libsplashscreen.so 412K 268K libfontmanager.so 1.4M 864K libjvm.so 19M 17M - the flag --print-gc-sections outputs the removed sections when calling the linker; this helps a lot to find coding "waiting for" cross-platform removal. Here is an example output of --print-gc-sections for the libnet-build (linux s390x) : /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file '/builddir/support/native/java.base/libnet/DefaultProxySelector.o' <--- seems to be dead /bin/ld: Removing unused section '.text.NET_ReadV' in file '/builddir/support/native/java.base/libnet/linux_close.o' <--- seems to be dead, I requested cross-platform removal with https://bugs.openjdk.java.net/browse/JDK-8234501 /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead /bin/ld: Removing unused section '.text.setDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed /bin/ld: Removing unused section '.text.getDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed /bin/ld: Removing unused section '.text.kernelIsV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in getDefaultScopeID , which is dead /bin/ld: Removing unused section '.bss.ni_class.8721' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in getDefaultScopeID , which is dead /bin/ld: Removing unused section '.bss.vinit24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in kernelIsV24 which is dead /bin/ld: Removing unused section '.bss.kernelV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in kernelIsV24 which is dead bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234525 http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/ Thanks, Matthias From matthias.baesken at sap.com Thu Nov 21 15:09:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Nov 2019 15:09:25 +0000 Subject: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Message-ID: Hello, I noticed that since today our jdk/jdk build fails on macOS . We run it on macOS 10.12 . It seems https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Brought a dependency on 10.13. Was that intended ? Could we keep 10.12 compatibility ? At least the doc of NSTextInputSourceIdentifier : https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier mentions macOS 10.13+ . Build errors are : ---------------------------- /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: error: unknown type name 'NSTextInputSourceIdentifier' NSTextInputSourceIdentifier kbdLayout; ^ /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: error: assignment to readonly property self.cglLayer = windowLayer; ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: error: assignment to readonly property self.cglLayer = nil; ~~~~~~~~~~~~~ ^ ~~~ 3 errors generated. ... /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: error: incompatible pointer to integer conversion initializing 'BOOL' (aka 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] BOOL mouseIsOver = [[window contentView] mouseIsOver]; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. Best regards, Matthias From vicente.romero at oracle.com Thu Nov 21 19:53:12 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Nov 2019 14:53:12 -0500 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> Message-ID: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> Hi, I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in this one, the code hasn't been split into different webrevs. I'm also forwarding to build-dev as there are some build related changes too. The CSR for this change is at [2] Thanks for all the comment so far, Vicente [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/ [2] https://bugs.openjdk.java.net/browse/JDK-8234596 On 11/20/19 8:21 PM, David Holmes wrote: > Correction ... > > On 21/11/2019 9:10 am, David Holmes wrote: >> Hi Vicente, >> >> Not sure the best mailing list for this review ... jdk-dev may not be >> well monitored. >> >> Is there a separate review thread for the actual tool removal (jdk.pack) > > I overlooked the removal of jdk.pack (scrolling too fast through the > webrev) - apologies. > > David > ----- > >> and build system changes? >> >> This removal seems okay, but I found one additional reference: >> >> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false >> >> >> Thanks, >> David >> ----- >> >> On 21/11/2019 8:54 am, Vicente Romero wrote: >>> Hi, >>> >>> I need a reviewer for the changes to remove pack200 and unpack200 >>> from the JDK. The webrev with the removal is at [1]. This patch is >>> the "implementation" of JEP 367 [2]. The patch is basically removing >>> the Pack200 related APIs plus its implementation plus any reference >>> to it in other tools like `jar`. In the case of `jar`, Pack200 was >>> only used if the `-n` flag was passed to the tool. I have removed >>> the code that was executed when that flag was passed. I have also >>> removed all the tests for Pack200. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022 From stefan.karlsson at oracle.com Thu Nov 21 21:11:20 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 21 Nov 2019 22:11:20 +0100 Subject: Fwd: RFR: 8233299: Implementation: JEP 365: ZGC on Windows In-Reply-To: <8fbffe58-7045-52e4-687c-35cb8c146365@oracle.com> References: <8fbffe58-7045-52e4-687c-35cb8c146365@oracle.com> Message-ID: <7a270142-d3d0-8276-43b3-f98dfa4b0cf8@oracle.com> Hi, I'm looking for a review for this tiny build change: https://cr.openjdk.java.net/~stefank/8233299/webrev.01/make/autoconf/hotspot.m4.udiff.html Thanks, StefanK -------- Forwarded Message -------- Subject: RFR: 8233299: Implementation: JEP 365: ZGC on Windows Date: Thu, 31 Oct 2019 11:18:20 +0100 From: Stefan Karlsson To: hotspot-gc-dev Hi all, Please review this patch to add ZGC support on Windows. https://cr.openjdk.java.net/~stefank/8233299/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8233299 As mentioned in the JEP (https://openjdk.java.net/jeps/365), there were some preparation patches that needed to go in to pave the way for this patch: 8232601: ZGC: Parameterize the ZGranuleMap table size 8232602: ZGC: Make ZGranuleMap ZAddress agnostic 8232604: ZGC: Make ZVerifyViews mapping and unmapping precise 8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations 8232649: ZGC: Add callbacks to ZMemoryManager 8232650: ZGC: Add initialization hooks for OS specific code 8232651: Add implementation of os::processor_id() for Windows ... they have all been pushed now. One important key-point to this implementation is to use the new Windows APIs that support reservation and mapping of memory through "placeholders": VirtualAlloc2, VirtualFreeEx, MapViewOfFile3, and UnmapViewOfFile2. These functions are available starting from version 1803 of Windows 10 and Windows Server. ZGC will lookup these symbols to determine if the Windows version supports these functions. Correlating the text in the JEP with the code: * '"Support for multi-mapping memory". ZGC's use of colored pointers requires support for heap multi-mapping, so that the same physical memory can be accessed from multiple different locations in the process address space. On Windows, paging-file backed memory provides physical memory with an identity (a handle), which is unrelated to the virtual address where it is mapped. Using this identity allows ZGC to map the same physical memory into multiple locations.' We commit memory via paging file mappings and map views into that memory. The function ZMapper::create_and_commit_paging_file_mapping uses CreateFileMappingW with SEC_RESERVE to create this mapping, MapViewOfFile3 to map a temporary view into the mapping, VirtualAlloc2 to commit the memory, and then UnmapViewOfFile2 to unmap the view. The reason to use SEC_RESERVE and the extra VirtualAlloc2, instead of SEC_COMMIT, is to ensure that the later multi-mappings of committed file mappings don't fail under low-memory situations. Earlier prototypes used SEC_COMMIT and saw these kind of OOME errors when mapping new views to already committed memory. The current platform-independent ZGC code isn't prepared to handle OOME errors when mapping views, so we chose this solution. MapViewOfFile3 is then used to multi-map into the committed memory. * '"Support for mapping paging-file backed memory into a reserved address space". The Windows memory management API is not as flexible as POSIX's mmap/munmap, especially when it comes to mapping file backed memory into a previously reserved address space region. To do this, ZGC will use the Windows concept of address space placeholders. The placeholder concept was introduced in version 1803 of Windows 10 and Windows Server. ZGC support for older versions of Windows will not be implemented.' Before the placeholder APIs there was no way to first reserve a specific virtual memory range, and then map a view of a committed paging file over that range. The VirtuaAlloc function could be used to first reserve and then commit anonymous memory, but nothing similar existed for mapped views. Now with placeholders, we can create a placeholder reservation of memory with VirtualAlloc2, and then replace that reservation with MapViewOfFile3. When memory is unmapped, we can use UnmapViewOfFile2 to "preserve" the placeholder memory reservation. * '"Support for mapping and unmapping arbitrary parts of the heap". ZGC's heap layout in combination with its dynamic sizing (and re-sizing) of heap pages requires support for mapping and unmapping arbitrary heap granules. This requirement in combination with Windows address space placeholders requires special attention, since placeholders must be explicitly split/coalesced by the program, as opposed to being automatically split/coalesced by the operating system (as on Linux).' Half of the preparation patches were put in place to support this. When replacing a placeholder with a view of the backing file, we need to exactly match the address and size of a placeholder. Also, when unmapping a view, we need to exactly match the address and size of the view, and replace it with a placeholder. To make it easier to map and unmap arbitrary parts of the heap, we split reserved memory into ZGranuleSize-sized placeholders. So, whenever we perform any of these operations, we know that any given memory range could be dealt with as a number of granules. When memory is reserved, but not mapped, it is registered in the ZVirtualMemoryManager. It splits memory into granule-sized placholders when reserved memory is fetched, and coalesces placeholders when reserved memory is handed back. * '"Support for committing and uncommitting arbitrary parts of the heap". ZGC can commit and uncommit physical memory dynamically while the Java program is running. To support these operations the physical memory will be divided into, and backed by, multiple paging-file segments. Each paging-file segment corresponds to a ZGC heap granule, and can be committed and uncommitted independently of other segments.' Just like we can map and unmap in granules, we want to be able to commit and uncommit memory in granules. You can see how memory is committed and uncommitted in granules in ZBackingFile::commit_from_paging_file and ZBackingFile::uncommit_from_paging_file. Each committed granule is associated with one registered handle. When memory for a granule is uncommitted, the handle is closed. At this point, no views exist to the mapping and the memory is handed back to the OS. Final point about ZPhysicalMemoryBacking. We've tried to make this file similar on all OSes, with the hope to be able to combine them when both the Windows and macOS ports have been merged. Thanks, StefanK From vicente.romero at oracle.com Thu Nov 21 22:22:40 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Nov 2019 17:22:40 -0500 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> Message-ID: <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com> please wait, I found some additional dependencies on module jdk.pack, will submit another webrev, sorry Vicente On 11/21/19 2:53 PM, Vicente Romero wrote: > Hi, > > I think I have covered all the proposed fixes so far. This is the last > iteration of the webrev [1], all the current changes are in this one, > the code hasn't been split into different webrevs. I'm also forwarding > to build-dev as there are some build related changes too. The CSR for > this change is at [2] > > Thanks for all the comment so far, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/ > [2] https://bugs.openjdk.java.net/browse/JDK-8234596 > > > > On 11/20/19 8:21 PM, David Holmes wrote: >> Correction ... >> >> On 21/11/2019 9:10 am, David Holmes wrote: >>> Hi Vicente, >>> >>> Not sure the best mailing list for this review ... jdk-dev may not >>> be well monitored. >>> >>> Is there a separate review thread for the actual tool removal >>> (jdk.pack) >> >> I overlooked the removal of jdk.pack (scrolling too fast through the >> webrev) - apologies. >> >> David >> ----- >> >>> and build system changes? >>> >>> This removal seems okay, but I found one additional reference: >>> >>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false >>> >>> >>> Thanks, >>> David >>> ----- >>> >>> On 21/11/2019 8:54 am, Vicente Romero wrote: >>>> Hi, >>>> >>>> I need a reviewer for the changes to remove pack200 and unpack200 >>>> from the JDK. The webrev with the removal is at [1]. This patch is >>>> the "implementation" of JEP 367 [2]. The patch is basically >>>> removing the Pack200 related APIs plus its implementation plus any >>>> reference to it in other tools like `jar`. In the case of `jar`, >>>> Pack200 was only used if the `-n` flag was passed to the tool. I >>>> have removed the code that was executed when that flag was passed. >>>> I have also removed all the tests for Pack200. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022 > From mandy.chung at oracle.com Thu Nov 21 22:45:12 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 21 Nov 2019 14:45:12 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com> Message-ID: <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com> CSR needs to mention that jar -n option is removed.? I made minor edit to the CSR to state that jdk.pack module is removed. Mandy On 11/21/19 2:22 PM, Vicente Romero wrote: > please wait, I found some additional dependencies on module jdk.pack, > will submit another webrev, sorry > > Vicente > > On 11/21/19 2:53 PM, Vicente Romero wrote: >> Hi, >> >> I think I have covered all the proposed fixes so far. This is the >> last iteration of the webrev [1], all the current changes are in this >> one, the code hasn't been split into different webrevs. I'm also >> forwarding to build-dev as there are some build related changes too. >> The CSR for this change is at [2] >> >> Thanks for all the comment so far, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8234596 >> >> >> >> On 11/20/19 8:21 PM, David Holmes wrote: >>> Correction ... >>> >>> On 21/11/2019 9:10 am, David Holmes wrote: >>>> Hi Vicente, >>>> >>>> Not sure the best mailing list for this review ... jdk-dev may not >>>> be well monitored. >>>> >>>> Is there a separate review thread for the actual tool removal >>>> (jdk.pack) >>> >>> I overlooked the removal of jdk.pack (scrolling too fast through the >>> webrev) - apologies. >>> >>> David >>> ----- >>> >>>> and build system changes? >>>> >>>> This removal seems okay, but I found one additional reference: >>>> >>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false >>>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 21/11/2019 8:54 am, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> I need a reviewer for the changes to remove pack200 and unpack200 >>>>> from the JDK. The webrev with the removal is at [1]. This patch is >>>>> the "implementation" of JEP 367 [2]. The patch is basically >>>>> removing the Pack200 related APIs plus its implementation plus any >>>>> reference to it in other tools like `jar`. In the case of `jar`, >>>>> Pack200 was only used if the `-n` flag was passed to the tool. I >>>>> have removed the code that was executed when that flag was passed. >>>>> I have also removed all the tests for Pack200. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/ >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022 >> > From vicente.romero at oracle.com Fri Nov 22 02:41:47 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 21 Nov 2019 21:41:47 -0500 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com> <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com> Message-ID: Hi Mandy, On 11/21/19 5:45 PM, Mandy Chung wrote: > CSR needs to mention that jar -n option is removed.? I made minor edit > to the CSR to state that jdk.pack module is removed. thanks for the changes, I added a mention to the jar -n option, > > Mandy Thanks, Vicente > > On 11/21/19 2:22 PM, Vicente Romero wrote: >> please wait, I found some additional dependencies on module jdk.pack, >> will submit another webrev, sorry >> >> Vicente >> >> On 11/21/19 2:53 PM, Vicente Romero wrote: >>> Hi, >>> >>> I think I have covered all the proposed fixes so far. This is the >>> last iteration of the webrev [1], all the current changes are in >>> this one, the code hasn't been split into different webrevs. I'm >>> also forwarding to build-dev as there are some build related changes >>> too. The CSR for this change is at [2] >>> >>> Thanks for all the comment so far, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8234596 >>> >>> >>> >>> On 11/20/19 8:21 PM, David Holmes wrote: >>>> Correction ... >>>> >>>> On 21/11/2019 9:10 am, David Holmes wrote: >>>>> Hi Vicente, >>>>> >>>>> Not sure the best mailing list for this review ... jdk-dev may not >>>>> be well monitored. >>>>> >>>>> Is there a separate review thread for the actual tool removal >>>>> (jdk.pack) >>>> >>>> I overlooked the removal of jdk.pack (scrolling too fast through >>>> the webrev) - apologies. >>>> >>>> David >>>> ----- >>>> >>>>> and build system changes? >>>>> >>>>> This removal seems okay, but I found one additional reference: >>>>> >>>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> On 21/11/2019 8:54 am, Vicente Romero wrote: >>>>>> Hi, >>>>>> >>>>>> I need a reviewer for the changes to remove pack200 and unpack200 >>>>>> from the JDK. The webrev with the removal is at [1]. This patch >>>>>> is the "implementation" of JEP 367 [2]. The patch is basically >>>>>> removing the Pack200 related APIs plus its implementation plus >>>>>> any reference to it in other tools like `jar`. In the case of >>>>>> `jar`, Pack200 was only used if the `-n` flag was passed to the >>>>>> tool. I have removed the code that was executed when that flag >>>>>> was passed. I have also removed all the tests for Pack200. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/ >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022 >>> >> > From Alan.Bateman at oracle.com Fri Nov 22 08:21:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Nov 2019 08:21:37 +0000 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> Message-ID: <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> On 21/11/2019 19:53, Vicente Romero wrote: > Hi, > > I think I have covered all the proposed fixes so far. This is the last > iteration of the webrev [1], all the current changes are in this one, > the code hasn't been split into different webrevs. I'm also forwarding > to build-dev as there are some build related changes too. The CSR for > this change is at [2] Would it be possible to summarize what will remain in test/jdk/tools/pack200 after this removal? The webrev makes it looks like badattr.jar is being added but since it already exists then I'm not sure whether to believe it. pack200-verifier/data/golden.jar is another one as it looks like JAR file that is generated by the tests today is being checked in, maybe `hg add` in error? The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, it's not immediately obvious to me which shared code compiled on Windows is impacted by this. -Alan From erik.joelsson at oracle.com Fri Nov 22 14:10:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 06:10:48 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> Message-ID: <72914fae-e43e-3ac1-6d2b-3e3b6de2b372@oracle.com> Looks good. /Erik On 2019-11-20 12:03, Mikael Vidstedt wrote: > > I noticed that most of the configure options include the default value > in the help string (in brackets), so here?s an updated webrev which > does exactly that: > > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01/open/webrev > Webrev (incremental): > http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01.incr/open/webrev/ > > Cheers, > Mikael > >> On Nov 20, 2019, at 7:47 AM, Erik Joelsson > > wrote: >> >> Looks good. >> >> /Erik >> >> On 2019-11-18 15:28, Mikael Vidstedt wrote: >>> Please review this change which implements the changes for JEP 362: >>> Deprecate the Solaris and SPARC Ports. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ >>> >>> I?ve tested that the expected error message is produced by default, >>> and that running with --enable-deprecated-ports=yes produces a >>> warning instead. >>> >>> Cheers, >>> Mikael >>> > From tim.bell at oracle.com Fri Nov 22 14:17:41 2019 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 22 Nov 2019 06:17:41 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <72914fae-e43e-3ac1-6d2b-3e3b6de2b372@oracle.com> References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> <72914fae-e43e-3ac1-6d2b-3e3b6de2b372@oracle.com> Message-ID: <524a8c93-745a-4bd4-1902-5091535c9f01@oracle.com> Mikael: Looks good to me as well. Tim On 2019-11-22 06:10, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2019-11-20 12:03, Mikael Vidstedt wrote: >> >> I noticed that most of the configure options include the default value >> in the help string (in brackets), so here?s an updated webrev which >> does exactly that: >> >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01/open/webrev >> Webrev (incremental): >> http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01.incr/open/webrev/ >> >> >> Cheers, >> Mikael >> >>> On Nov 20, 2019, at 7:47 AM, Erik Joelsson >> > wrote: >>> >>> Looks good. >>> >>> /Erik >>> >>> On 2019-11-18 15:28, Mikael Vidstedt wrote: >>>> Please review this change which implements the changes for JEP 362: >>>> Deprecate the Solaris and SPARC Ports. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 >>>> Webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ >>>> >>>> >>>> I?ve tested that the expected error message is produced by default, >>>> and that running with --enable-deprecated-ports=yes produces a >>>> warning instead. >>>> >>>> Cheers, >>>> Mikael >>>> >> From erik.joelsson at oracle.com Fri Nov 22 14:23:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 06:23:00 -0800 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hello Matthias, This looks like an interesting change. If you want to enable this for s390x, I'm ok with it. If it works out well, perhaps we can find a way to expand this to other architectures. Do you really want to set --print-gc-sections by default? I would assume that makes the build quite chatty. /Erik On 2019-11-21 00:54, Baesken, Matthias wrote: > Hello, > > gcc and ld can be instructed to work together to "garbage collect" unused input sections. > This feature eliminates unused code from native libraries. As a prerequisite to take full advantage of the feature, > the source files need to be compiled with "-ffunction-sections -fdata-sections". > > Details on what happens can be found in the ld documentation: https://linux.die.net/man/1/ld . > See the description of --gc-sections and --print-gc-sections therein. > For more detailed insights there is a talk available from ELC2010: https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf > > My change enables the unused code elimination on linux s390x . > (on the other Linux platforms, there are still issues to be solved with the serviceability agent, but we do not have the serviceability agent on linux s390x). > > The change has 2 benefits : > - native libs with unused code get smaller (some get alot smaller) > some example lib sizes from linuxs390x (product build) : > default settings / link-time gc-sections > libmlib_image.so 556K 536K > libjavajpeg.so 300K 292K > libsplashscreen.so 412K 268K > libfontmanager.so 1.4M 864K > libjvm.so 19M 17M > > - the flag --print-gc-sections outputs the removed sections when calling the linker; > this helps a lot to find coding "waiting for" cross-platform removal. > > > Here is an example output of --print-gc-sections for the libnet-build (linux s390x) : > > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file '/builddir/support/native/java.base/libnet/DefaultProxySelector.o' <--- seems to be dead > /bin/ld: Removing unused section '.text.NET_ReadV' in file '/builddir/support/native/java.base/libnet/linux_close.o' <--- seems to be dead, I requested cross-platform removal with https://bugs.openjdk.java.net/browse/JDK-8234501 > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be dead > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed > /bin/ld: Removing unused section '.text.kernelIsV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to be dead indeed > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in getDefaultScopeID , which is dead > /bin/ld: Removing unused section '.bss.ni_class.8721' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in getDefaultScopeID , which is dead > /bin/ld: Removing unused section '.bss.vinit24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in kernelIsV24 which is dead > /bin/ld: Removing unused section '.bss.kernelV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used in kernelIsV24 which is dead > > bug/webrev : > https://bugs.openjdk.java.net/browse/JDK-8234525 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/ > > Thanks, Matthias > > From erik.joelsson at oracle.com Fri Nov 22 14:24:34 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 06:24:34 -0800 Subject: Fwd: RFR: 8233299: Implementation: JEP 365: ZGC on Windows In-Reply-To: <7a270142-d3d0-8276-43b3-f98dfa4b0cf8@oracle.com> References: <8fbffe58-7045-52e4-687c-35cb8c146365@oracle.com> <7a270142-d3d0-8276-43b3-f98dfa4b0cf8@oracle.com> Message-ID: <366b3944-b22f-98f5-24d2-76cdea44ce89@oracle.com> Build change looks good. /Erik On 2019-11-21 13:11, Stefan Karlsson wrote: > Hi, > > I'm looking for a review for this tiny build change: > https://cr.openjdk.java.net/~stefank/8233299/webrev.01/make/autoconf/hotspot.m4.udiff.html > > > Thanks, > StefanK > > -------- Forwarded Message -------- > Subject:???? RFR: 8233299: Implementation: JEP 365: ZGC on Windows > Date:???? Thu, 31 Oct 2019 11:18:20 +0100 > From:???? Stefan Karlsson > To:???? hotspot-gc-dev > > > > Hi all, > > Please review this patch to add ZGC support on Windows. > > https://cr.openjdk.java.net/~stefank/8233299/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8233299 > > As mentioned in the JEP (https://openjdk.java.net/jeps/365), there > were some preparation patches that needed to go in to pave the way for > this patch: > > 8232601: ZGC: Parameterize the ZGranuleMap table size > 8232602: ZGC: Make ZGranuleMap ZAddress agnostic > 8232604: ZGC: Make ZVerifyViews mapping and unmapping precise > 8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations > 8232649: ZGC: Add callbacks to ZMemoryManager > 8232650: ZGC: Add initialization hooks for OS specific code > 8232651: Add implementation of os::processor_id() for Windows > > ... they have all been pushed now. > > One important key-point to this implementation is to use the new > Windows APIs that support reservation and mapping of memory through > "placeholders": VirtualAlloc2, VirtualFreeEx, MapViewOfFile3, and > UnmapViewOfFile2. These functions are available starting from version > 1803 of Windows 10 and Windows Server. ZGC will lookup these symbols > to determine if the Windows version supports these functions. > > > Correlating the text in the JEP with the code: > > * '"Support for multi-mapping memory". ZGC's use of colored pointers > requires support for heap multi-mapping, so that the same physical > memory can be accessed from multiple different locations in the > process address space. On Windows, paging-file backed memory provides > physical memory with an identity (a handle), which is unrelated to the > virtual address where it is mapped. Using this identity allows ZGC to > map the same physical memory into multiple locations.' > > We commit memory via paging file mappings and map views into that memory. > > The function ZMapper::create_and_commit_paging_file_mapping uses > CreateFileMappingW with SEC_RESERVE to create this mapping, > MapViewOfFile3 to map a temporary view into the mapping, VirtualAlloc2 > to commit the memory, and then UnmapViewOfFile2 to unmap the view. > > The reason to use SEC_RESERVE and the extra VirtualAlloc2, instead of > SEC_COMMIT, is to ensure that the later multi-mappings of committed > file mappings don't fail under low-memory situations. Earlier > prototypes used SEC_COMMIT and saw these kind of OOME errors when > mapping new views to already committed memory. The current > platform-independent ZGC code isn't prepared to handle OOME errors > when mapping views, so we chose this solution. > > MapViewOfFile3 is then used to multi-map into the committed memory. > > * '"Support for mapping paging-file backed memory into a reserved > address space". The Windows memory management API is not as flexible > as POSIX's mmap/munmap, especially when it comes to mapping file > backed memory into a previously reserved address space region. To do > this, ZGC will use the Windows concept of address space placeholders. > The placeholder concept was introduced in version 1803 of Windows 10 > and Windows Server. ZGC support for older versions of Windows will not > be implemented.' > > Before the placeholder APIs there was no way to first reserve a > specific virtual memory range, and then map a view of a committed > paging file over that range. The VirtuaAlloc function could be used to > first reserve and then commit anonymous memory, but nothing similar > existed for mapped views. Now with placeholders, we can create a > placeholder reservation of memory with VirtualAlloc2, and then replace > that reservation with MapViewOfFile3. When memory is unmapped, we can > use UnmapViewOfFile2 to "preserve" the placeholder memory reservation. > > > * '"Support for mapping and unmapping arbitrary parts of the heap". > ZGC's heap layout in combination with its dynamic sizing (and > re-sizing) of heap pages requires support for mapping and unmapping > arbitrary heap granules. This requirement in combination with Windows > address space placeholders requires special attention, since > placeholders must be explicitly split/coalesced by the program, as > opposed to being automatically split/coalesced by the operating system > (as on Linux).' > > Half of the preparation patches were put in place to support this. > When replacing a placeholder with a view of the backing file, we need > to exactly match the address and size of a placeholder. Also, when > unmapping a view, we need to exactly match the address and size of the > view, and replace it with a placeholder. > > To make it easier to map and unmap arbitrary parts of the heap, we > split reserved memory into ZGranuleSize-sized placeholders. So, > whenever we perform any of these operations, we know that any given > memory range could be dealt with as a number of granules. > > When memory is reserved, but not mapped, it is registered in the > ZVirtualMemoryManager. It splits memory into granule-sized placholders > when reserved memory is fetched, and coalesces placeholders when > reserved memory is handed back. > > > * '"Support for committing and uncommitting arbitrary parts of the > heap". ZGC can commit and uncommit physical memory dynamically while > the Java program is running. To support these operations the physical > memory will be divided into, and backed by, multiple paging-file > segments. Each paging-file segment corresponds to a ZGC heap granule, > and can be committed and uncommitted independently of other segments.' > > Just like we can map and unmap in granules, we want to be able to > commit and uncommit memory in granules. You can see how memory is > committed and uncommitted in granules in > ZBackingFile::commit_from_paging_file and > ZBackingFile::uncommit_from_paging_file. Each committed granule is > associated with one registered handle. When memory for a granule is > uncommitted, the handle is closed. At this point, no views exist to > the mapping and the memory is handed back to the OS. > > > Final point about ZPhysicalMemoryBacking. We've tried to make this > file similar on all OSes, with the hope to be able to combine them > when both the Windows and macOS ports have been merged. > > Thanks, > StefanK From matthias.baesken at sap.com Fri Nov 22 15:00:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 22 Nov 2019 15:00:41 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hi Erik, yes it makes the build more chatty - our linux s390 product build log of jdk/jdk goes from ~ 60.000 lines to ~ 123.000 lines with the patch. However the change is linux s390 only so I guess it will not disturb other people ( in case we bring it to more platforms later on, we could remove the printing or make it configurable ). Additionally the "chatty" output is used currently for eliminating unused functions + data cross-platform (see for example https://bugs.openjdk.java.net/browse/JDK-8234629 ). Best regards, Matthias > > Hello Matthias, > > This looks like an interesting change. If you want to enable this for > s390x, I'm ok with it. If it works out well, perhaps we can find a way > to expand this to other architectures. > > Do you really want to set --print-gc-sections by default? I would assume > that makes the build quite chatty. > > /Erik > > On 2019-11-21 00:54, Baesken, Matthias wrote: > > Hello, > > > > gcc and ld can be instructed to work together to "garbage collect" unused > input sections. > > This feature eliminates unused code from native libraries. As a prerequisite > to take full advantage of the feature, > > the source files need to be compiled with "-ffunction-sections -fdata- > sections". > > > > Details on what happens can be found in the ld documentation: > https://linux.die.net/man/1/ld . > > See the description of --gc-sections and --print-gc-sections therein. > > For more detailed insights there is a talk available from ELC2010: > https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf > > > > My change enables the unused code elimination on linux s390x . > > (on the other Linux platforms, there are still issues to be solved with the > serviceability agent, but we do not have the serviceability agent on linux > s390x). > > > > The change has 2 benefits : > > - native libs with unused code get smaller (some get alot smaller) > > some example lib sizes from linuxs390x (product build) : > > default settings / link-time gc-sections > > libmlib_image.so 556K 536K > > libjavajpeg.so 300K 292K > > libsplashscreen.so 412K 268K > > libfontmanager.so 1.4M 864K > > libjvm.so 19M 17M > > > > - the flag --print-gc-sections outputs the removed sections when calling > the linker; > > this helps a lot to find coding "waiting for" cross-platform removal. > > > > > > Here is an example output of --print-gc-sections for the libnet-build (linux > s390x) : > > > > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file > '/builddir/support/native/java.base/libnet/DefaultProxySelector.o' <--- > seems to be dead > > /bin/ld: Removing unused section '.text.NET_ReadV' in file > '/builddir/support/native/java.base/libnet/linux_close.o' <--- seems > to be dead, I requested cross-platform removal with > https://bugs.openjdk.java.net/browse/JDK-8234501 > > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be > dead > > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be > dead > > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file > '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be > dead > > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to > be dead indeed > > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems to > be dead indeed > > /bin/ld: Removing unused section '.text.kernelIsV24' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > seems to be dead indeed > > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only used > in getDefaultScopeID , which is dead > > /bin/ld: Removing unused section '.bss.ni_class.8721' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > used in getDefaultScopeID , which is dead > > /bin/ld: Removing unused section '.bss.vinit24' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > only used in kernelIsV24 which is dead > > /bin/ld: Removing unused section '.bss.kernelV24' in file > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > used in kernelIsV24 which is dead > > > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/ > > > > Thanks, Matthias > > > > From stefan.karlsson at oracle.com Fri Nov 22 15:37:52 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 22 Nov 2019 16:37:52 +0100 Subject: Fwd: RFR: 8233299: Implementation: JEP 365: ZGC on Windows In-Reply-To: <366b3944-b22f-98f5-24d2-76cdea44ce89@oracle.com> References: <8fbffe58-7045-52e4-687c-35cb8c146365@oracle.com> <7a270142-d3d0-8276-43b3-f98dfa4b0cf8@oracle.com> <366b3944-b22f-98f5-24d2-76cdea44ce89@oracle.com> Message-ID: <9e26208b-d623-7754-0544-b625e85fc64b@oracle.com> Thanks, Erik. StefanK On 2019-11-22 15:24, Erik Joelsson wrote: > Build change looks good. > > /Erik > > On 2019-11-21 13:11, Stefan Karlsson wrote: >> Hi, >> >> I'm looking for a review for this tiny build change: >> https://cr.openjdk.java.net/~stefank/8233299/webrev.01/make/autoconf/hotspot.m4.udiff.html >> >> >> Thanks, >> StefanK >> >> -------- Forwarded Message -------- >> Subject:???? RFR: 8233299: Implementation: JEP 365: ZGC on Windows >> Date:???? Thu, 31 Oct 2019 11:18:20 +0100 >> From:???? Stefan Karlsson >> To:???? hotspot-gc-dev >> >> >> >> Hi all, >> >> Please review this patch to add ZGC support on Windows. >> >> https://cr.openjdk.java.net/~stefank/8233299/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8233299 >> >> As mentioned in the JEP (https://openjdk.java.net/jeps/365), there >> were some preparation patches that needed to go in to pave the way for >> this patch: >> >> 8232601: ZGC: Parameterize the ZGranuleMap table size >> 8232602: ZGC: Make ZGranuleMap ZAddress agnostic >> 8232604: ZGC: Make ZVerifyViews mapping and unmapping precise >> 8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations >> 8232649: ZGC: Add callbacks to ZMemoryManager >> 8232650: ZGC: Add initialization hooks for OS specific code >> 8232651: Add implementation of os::processor_id() for Windows >> >> ... they have all been pushed now. >> >> One important key-point to this implementation is to use the new >> Windows APIs that support reservation and mapping of memory through >> "placeholders": VirtualAlloc2, VirtualFreeEx, MapViewOfFile3, and >> UnmapViewOfFile2. These functions are available starting from version >> 1803 of Windows 10 and Windows Server. ZGC will lookup these symbols >> to determine if the Windows version supports these functions. >> >> >> Correlating the text in the JEP with the code: >> >> * '"Support for multi-mapping memory". ZGC's use of colored pointers >> requires support for heap multi-mapping, so that the same physical >> memory can be accessed from multiple different locations in the >> process address space. On Windows, paging-file backed memory provides >> physical memory with an identity (a handle), which is unrelated to the >> virtual address where it is mapped. Using this identity allows ZGC to >> map the same physical memory into multiple locations.' >> >> We commit memory via paging file mappings and map views into that memory. >> >> The function ZMapper::create_and_commit_paging_file_mapping uses >> CreateFileMappingW with SEC_RESERVE to create this mapping, >> MapViewOfFile3 to map a temporary view into the mapping, VirtualAlloc2 >> to commit the memory, and then UnmapViewOfFile2 to unmap the view. >> >> The reason to use SEC_RESERVE and the extra VirtualAlloc2, instead of >> SEC_COMMIT, is to ensure that the later multi-mappings of committed >> file mappings don't fail under low-memory situations. Earlier >> prototypes used SEC_COMMIT and saw these kind of OOME errors when >> mapping new views to already committed memory. The current >> platform-independent ZGC code isn't prepared to handle OOME errors >> when mapping views, so we chose this solution. >> >> MapViewOfFile3 is then used to multi-map into the committed memory. >> >> * '"Support for mapping paging-file backed memory into a reserved >> address space". The Windows memory management API is not as flexible >> as POSIX's mmap/munmap, especially when it comes to mapping file >> backed memory into a previously reserved address space region. To do >> this, ZGC will use the Windows concept of address space placeholders. >> The placeholder concept was introduced in version 1803 of Windows 10 >> and Windows Server. ZGC support for older versions of Windows will not >> be implemented.' >> >> Before the placeholder APIs there was no way to first reserve a >> specific virtual memory range, and then map a view of a committed >> paging file over that range. The VirtuaAlloc function could be used to >> first reserve and then commit anonymous memory, but nothing similar >> existed for mapped views. Now with placeholders, we can create a >> placeholder reservation of memory with VirtualAlloc2, and then replace >> that reservation with MapViewOfFile3. When memory is unmapped, we can >> use UnmapViewOfFile2 to "preserve" the placeholder memory reservation. >> >> >> * '"Support for mapping and unmapping arbitrary parts of the heap". >> ZGC's heap layout in combination with its dynamic sizing (and >> re-sizing) of heap pages requires support for mapping and unmapping >> arbitrary heap granules. This requirement in combination with Windows >> address space placeholders requires special attention, since >> placeholders must be explicitly split/coalesced by the program, as >> opposed to being automatically split/coalesced by the operating system >> (as on Linux).' >> >> Half of the preparation patches were put in place to support this. >> When replacing a placeholder with a view of the backing file, we need >> to exactly match the address and size of a placeholder. Also, when >> unmapping a view, we need to exactly match the address and size of the >> view, and replace it with a placeholder. >> >> To make it easier to map and unmap arbitrary parts of the heap, we >> split reserved memory into ZGranuleSize-sized placeholders. So, >> whenever we perform any of these operations, we know that any given >> memory range could be dealt with as a number of granules. >> >> When memory is reserved, but not mapped, it is registered in the >> ZVirtualMemoryManager. It splits memory into granule-sized placholders >> when reserved memory is fetched, and coalesces placeholders when >> reserved memory is handed back. >> >> >> * '"Support for committing and uncommitting arbitrary parts of the >> heap". ZGC can commit and uncommit physical memory dynamically while >> the Java program is running. To support these operations the physical >> memory will be divided into, and backed by, multiple paging-file >> segments. Each paging-file segment corresponds to a ZGC heap granule, >> and can be committed and uncommitted independently of other segments.' >> >> Just like we can map and unmap in granules, we want to be able to >> commit and uncommit memory in granules. You can see how memory is >> committed and uncommitted in granules in >> ZBackingFile::commit_from_paging_file and >> ZBackingFile::uncommit_from_paging_file. Each committed granule is >> associated with one registered handle. When memory for a granule is >> uncommitted, the handle is closed. At this point, no views exist to >> the mapping and the memory is handed back to the OS. >> >> >> Final point about ZPhysicalMemoryBacking. We've tried to make this >> file similar on all OSes, with the hope to be able to combine them >> when both the Windows and macOS ports have been merged. >> >> Thanks, >> StefanK From erik.joelsson at oracle.com Fri Nov 22 16:19:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 08:19:08 -0800 Subject: RFR: 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <20191120182355.20831DDD26@aojmv0009> References: <20191120182355.20831DDD26@aojmv0009> Message-ID: <82089f9b-ba48-5fc2-b485-3b17997663de@oracle.com> Hello Christoph, On 2019-11-20 10:22, christoph.goettschkes at microdoc.com wrote: > Hi, > > please review the following change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev.00/ > > The removed lines are completely out of place and have no use at all. for > the CC variable, for instance, the script does the following: > > CC_OLD="$CC" > CC="$BUILD_CC" > CC="$CC_OLD" > > without executing any function between those lines. I think that, while > restructuring the build system, those lines have been copied to the wrong > location. I copied them around the "FLAGS_SETUP_CFLAGS_CPU_DEP" call for > the BUILD_CC, in order to make configure not use the target CFLAGS while > discovering possible CFLAGS for the BUILD_CC, which was happening in our > case. Wow, I had not noticed that. Your fix looks correct. > I am also not sure if the variable BUILD_CC_DISABLE_WARNING_PREFIX is > actually used anywhere. I could not find any user and it might be possible > to simply remove it. It's used to override DISABLE_WARNING_PREFIX in buildjdk-spec.gmk so I think it serves a purpose, even if we don't actually support different toolchain types for cross and native compiler. If we ever will, then this variable will be needed, so I think it should stay. > I tried the change and compiled on an amd64 linux machine for amd64, and > cross-compiled for linux on armv7 and linux on aarch64. I don't have > access to other cross-compilation environments and would like to ask > others to review and try out the change. I applied the patch and tried a few of our configurations. Since we use the same (or close to the same) compiler versions across architectures, I don't actually see any difference in the generated spec files. The reason you see this is the large version difference between your compilers. Looks good, thanks for finding and fixing this! /Erik > Thanks, > Christoph > From mikael.vidstedt at oracle.com Fri Nov 22 19:01:02 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 22 Nov 2019 11:01:02 -0800 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <524a8c93-745a-4bd4-1902-5091535c9f01@oracle.com> References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> <72914fae-e43e-3ac1-6d2b-3e3b6de2b372@oracle.com> <524a8c93-745a-4bd4-1902-5091535c9f01@oracle.com> Message-ID: Erik/Tim, thanks for the reviews! On more small change: Update building.md (and .html) to reflect the deprecation of the ports: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.02.incr/open/webrev/ Let me know if you think of other places where this should be reflected. Cheers, Mikael > On Nov 22, 2019, at 6:17 AM, Tim Bell wrote: > > Mikael: > > Looks good to me as well. > > Tim > > On 2019-11-22 06:10, Erik Joelsson wrote: >> Looks good. >> /Erik >> On 2019-11-20 12:03, Mikael Vidstedt wrote: >>> >>> I noticed that most of the configure options include the default value in the help string (in brackets), so here?s an updated webrev which does exactly that: >>> >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01/open/webrev >>> Webrev (incremental): http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.01.incr/open/webrev/ >>> >>> Cheers, >>> Mikael >>> >>>> On Nov 20, 2019, at 7:47 AM, Erik Joelsson > wrote: >>>> >>>> Looks good. >>>> >>>> /Erik >>>> >>>> On 2019-11-18 15:28, Mikael Vidstedt wrote: >>>>> Please review this change which implements the changes for JEP 362: Deprecate the Solaris and SPARC Ports. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234370 >>>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.00/open/webrev/ >>>>> >>>>> I?ve tested that the expected error message is produced by default, and that running with --enable-deprecated-ports=yes produces a warning instead. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>> > From glaubitz at physik.fu-berlin.de Fri Nov 22 19:39:18 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 22 Nov 2019 20:39:18 +0100 Subject: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports In-Reply-To: References: <8FD75264-5B14-4B15-A41E-B4295982C928@oracle.com> <855b0d4c-5f85-41da-611e-e4c3c46e69b2@oracle.com> <72914fae-e43e-3ac1-6d2b-3e3b6de2b372@oracle.com> <524a8c93-745a-4bd4-1902-5091535c9f01@oracle.com> Message-ID: <69f4f854-98cc-efff-4f93-0027a2444d5d@physik.fu-berlin.de> Hi! On 11/22/19 8:01 PM, Mikael Vidstedt wrote: > Erik/Tim, thanks for the reviews! > > On more small change: Update building.md (and .html) to reflect the deprecation of the ports: > > http://cr.openjdk.java.net/~mikael/webrevs/8234370/webrev.02.incr/open/webrev/ > > Let me know if you think of other places where this should be reflected. Out of curiosity: With Oracle Solaris officially being supported until at least 2034, does that mean the SPARC port of OpenJDK-11 will be maintained until 2034 as well? So far I don't understand the reasoning behind deprecating Solaris SPARC when the platform has still official support until 2034. The last SPARC CPU was the M8 which was released 2017. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From vicente.romero at oracle.com Fri Nov 22 21:30:42 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 22 Nov 2019 16:30:42 -0500 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> Message-ID: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Hi all, On 11/22/19 3:21 AM, Alan Bateman wrote: > > > On 21/11/2019 19:53, Vicente Romero wrote: >> Hi, >> >> I think I have covered all the proposed fixes so far. This is the >> last iteration of the webrev [1], all the current changes are in this >> one, the code hasn't been split into different webrevs. I'm also >> forwarding to build-dev as there are some build related changes too. >> The CSR for this change is at [2] > Would it be possible to summarize what will remain in > test/jdk/tools/pack200 after this removal? The webrev makes it looks > like badattr.jar is being added but since it already exists then I'm > not sure whether to believe it. pack200-verifier/data/golden.jar is > another one as it looks like JAR file that is generated by the tests > today is being checked in, maybe `hg add` in error? I don't know why it is shown as added in the webrev, they have been removed. I have published another iteration of the webrev at [1] > > The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, > it's not immediately obvious to me which shared code compiled on > Windows is impacted by this. yes probably this change is risky. I did it as the comment suggested that the only reason the treatment for Windows was different was because of pack200. But not sure if we can trust that comment. Should I restore this code to its original state? > > -Alan Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From erik.joelsson at oracle.com Fri Nov 22 21:41:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 13:41:56 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: Hello, On 2019-11-22 13:30, Vicente Romero wrote: > Hi all, > > On 11/22/19 3:21 AM, Alan Bateman wrote: >> >> >> On 21/11/2019 19:53, Vicente Romero wrote: >>> Hi, >>> >>> I think I have covered all the proposed fixes so far. This is the >>> last iteration of the webrev [1], all the current changes are in >>> this one, the code hasn't been split into different webrevs. I'm >>> also forwarding to build-dev as there are some build related changes >>> too. The CSR for this change is at [2] >> Would it be possible to summarize what will remain in >> test/jdk/tools/pack200 after this removal? The webrev makes it looks >> like badattr.jar is being added but since it already exists then I'm >> not sure whether to believe it. pack200-verifier/data/golden.jar is >> another one as it looks like JAR file that is generated by the tests >> today is being checked in, maybe `hg add` in error? > > I don't know why it is shown as added in the webrev, they have been > removed. I have published another iteration of the webrev at [1] >> >> The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, >> it's not immediately obvious to me which shared code compiled on >> Windows is impacted by this. > > yes probably this change is risky. I did it as the comment suggested > that the only reason the treatment for Windows was different was > because of pack200. But not sure if we can trust that comment. Should > I restore this code to its original state? >> That comment is most likely originating from the build-infra rewrite in JDK 8. We probably added _LP64 on all platforms by mistake and noted that it caused a difference in the pack200 binary, so corrected the new build to mimic the old build. I wouldn't say just adding _LP64 on Windows is correct because of this. It may be correct regardless, or it may not. In make/scripts/compare.sh $UNPACK200 is still referenced. Should probably remove the whole section using it rather than just removing the string "jdk.pack". I would assume the *.pack and *.pack.gz files are long gone from any build. /Erik >> -Alan > > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From weijun.wang at oracle.com Sat Nov 23 02:59:43 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Nov 2019 10:59:43 +0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build Message-ID: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> Please review the change at http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. Other smaller changes made to FieldGen.jsh: 1. Package name 2. No more jshell, but now Java 3. Input/output paths as args for main() 4. White spaces, wrapping and indentation Thanks, Max From matthias.baesken at sap.com Mon Nov 25 12:48:04 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Nov 2019 12:48:04 +0000 Subject: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Message-ID: Hello, any comments on the issue ? Could we maybe switch from using NSTextInputSourceIdentifier to String (NSString* ?) , because https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier says NSTextInputSourceIdentifier is a typealias for String ? Best regards ,Matthias Hello, I noticed that since today our jdk/jdk build fails on macOS . We run it on macOS 10.12 . It seems https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Brought a dependency on 10.13. Was that intended ? Could we keep 10.12 compatibility ? At least the doc of NSTextInputSourceIdentifier : https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier mentions macOS 10.13+ . Build errors are : ---------------------------- /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: error: unknown type name 'NSTextInputSourceIdentifier' NSTextInputSourceIdentifier kbdLayout; ^ /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: error: assignment to readonly property self.cglLayer = windowLayer; ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: error: assignment to readonly property self.cglLayer = nil; ~~~~~~~~~~~~~ ^ ~~~ 3 errors generated. ... /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: error: incompatible pointer to integer conversion initializing 'BOOL' (aka 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] BOOL mouseIsOver = [[window contentView] mouseIsOver]; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. Best regards, Matthias From matthias.baesken at sap.com Mon Nov 25 14:42:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Nov 2019 14:42:05 +0000 Subject: binary Hardening on linux using Relocation Read-Only (relro) Message-ID: Hello, I wonder why the binary hardening on linux using Relocation Read-Only (relro) is not enabled by default. Some info can be found here : https://wiki.debian.org/Hardening https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro Currently I notice the settings only for debug / fastdebug builds , see flags-ldflags.m4 : # Setup debug level-dependent LDFLAGS if test "x$TOOLCHAIN_TYPE" = xgcc; then if test "x$OPENJDK_TARGET_OS" = xlinux; then if test x$DEBUG_LEVEL = xrelease; then DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -Wl,-O1" else # mark relocations read only on (fast/slow) debug builds DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" fi if test x$DEBUG_LEVEL = xslowdebug; then # do relocations at load DEBUGLEVEL_LDFLAGS="-Wl,-z,now" fi fi Shouldn't we use at least "-Wl,-z,relro" also on product builds ? For "-Wl,-z,now" some startup performance hits are mentioned in articles/blogs - any experiences / performance-measurements with this in the OpenJDK context ? Best regards, Matthias From erik.joelsson at oracle.com Mon Nov 25 16:36:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Nov 2019 08:36:09 -0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> Message-ID: <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> Build change looks good. /Erik On 2019-11-22 18:59, Weijun Wang wrote: > Please review the change at > > http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ > > The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. > > I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. > > Other smaller changes made to FieldGen.jsh: > > 1. Package name > 2. No more jshell, but now Java > 3. Input/output paths as args for main() > 4. White spaces, wrapping and indentation > > Thanks, > Max > From erik.joelsson at oracle.com Mon Nov 25 16:37:20 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Nov 2019 08:37:20 -0800 Subject: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: Message-ID: If there is a simple fix, I would very much like to see it done. I'm not familiar enough with this area to know what the implications would be though. /Erik On 2019-11-25 04:48, Baesken, Matthias wrote: > Hello, any comments on the issue ? > > Could we maybe switch from using > > NSTextInputSourceIdentifier > > to > > String (NSString* ?) , because https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier > > says NSTextInputSourceIdentifier is a typealias for String ? > > Best regards ,Matthias > > > > > Hello, I noticed that since today our jdk/jdk build fails on macOS . We run it on macOS 10.12 . > > It seems > https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > > 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings > > Brought a dependency on 10.13. Was that intended ? Could we keep 10.12 compatibility ? > At least the doc of NSTextInputSourceIdentifier : https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier > mentions macOS 10.13+ . > > > > Build errors are : > ---------------------------- > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: error: unknown type name 'NSTextInputSourceIdentifier' > NSTextInputSourceIdentifier kbdLayout; > ^ > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: error: assignment to readonly property > self.cglLayer = windowLayer; > ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: error: assignment to readonly property > self.cglLayer = nil; > ~~~~~~~~~~~~~ ^ ~~~ > 3 errors generated. > > > ... > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: error: incompatible pointer to integer conversion initializing 'BOOL' (aka 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] > BOOL mouseIsOver = [[window contentView] mouseIsOver]; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 2 errors generated. > > > > Best regards, Matthias From erik.joelsson at oracle.com Mon Nov 25 16:41:46 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Nov 2019 08:41:46 -0800 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: References: Message-ID: <6de2e634-eace-68c6-c86c-f0e51474745b@oracle.com> Hello, I wasn't directly involved in introducing these flags, but my understanding is that it's always a performance compromise. I would involve at least hotspot-dev for a wider discussion on this as libjvm is the most affected library. /Erik On 2019-11-25 06:42, Baesken, Matthias wrote: > Hello, I wonder why the binary hardening on linux using Relocation Read-Only (relro) is not enabled by default. > > Some info can be found here : > > https://wiki.debian.org/Hardening > > https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro > > > Currently I notice the settings only for debug / fastdebug builds , see flags-ldflags.m4 : > > # Setup debug level-dependent LDFLAGS > if test "x$TOOLCHAIN_TYPE" = xgcc; then > if test "x$OPENJDK_TARGET_OS" = xlinux; then > if test x$DEBUG_LEVEL = xrelease; then > DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -Wl,-O1" > else > # mark relocations read only on (fast/slow) debug builds > DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" > fi > if test x$DEBUG_LEVEL = xslowdebug; then > # do relocations at load > DEBUGLEVEL_LDFLAGS="-Wl,-z,now" > fi > fi > > Shouldn't we use at least "-Wl,-z,relro" also on product builds ? > > For "-Wl,-z,now" some startup performance hits are mentioned in articles/blogs - any experiences / performance-measurements with this in the OpenJDK context ? > > Best regards, Matthias > From philip.race at oracle.com Mon Nov 25 16:57:40 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Nov 2019 08:57:40 -0800 Subject: [OpenJDK 2D-Dev] build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: Message-ID: I expect we could as it would help with backports but how much longer can we support 10.12 SDK to build ? Project Lanai is already finding it hard to keep to the 10.13 SDK ... and 10.12 as an O/S is already EOSL. So it should just be a stop gap measure. -phil. On 11/25/19 4:48 AM, Baesken, Matthias wrote: > > Hello,? any comments on the issue ? > > Could we maybe switch from using > > NSTextInputSourceIdentifier > > to > > String? (NSString* ?) , because > https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier > > says ?NSTextInputSourceIdentifier?? ?is a typealias for String? ? > > Best regards ,Matthias > > Hello, I noticed? that since today our? jdk/jdk? build fails on macOS > . We run it on macOS 10.12 . > > It seems > > https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > > 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java > ignores system settings > > Brought a? dependency on 10.13.? Was that intended ? Could we keep > 10.12 ?compatibility ? > > At least ?the doc of NSTextInputSourceIdentifier? : > https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier > > mentions ?macOS 10.13+? . > > Build errors are : > > ---------------------------- > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: > error: unknown type name 'NSTextInputSourceIdentifier' > > NSTextInputSourceIdentifier kbdLayout; > > ??? ^ > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: > error: assignment to readonly property > > ??????? self.cglLayer = windowLayer; > > ??????? ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: > error: assignment to readonly property > > ??? self.cglLayer = nil; > > ??? ~~~~~~~~~~~~~ ^ ~~~ > > 3 errors generated. > > ? > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: > error: incompatible pointer to integer conversion initializing 'BOOL' > (aka 'signed char') with an expression of type 'id' > [-Werror,-Wint-conversion] > > ??????????? BOOL mouseIsOver = [[window contentView] mouseIsOver]; > > ^ ????????????~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2 errors generated. > > Best regards, Matthias > From fweimer at redhat.com Mon Nov 25 17:30:49 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 25 Nov 2019 18:30:49 +0100 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: (Matthias Baesken's message of "Mon, 25 Nov 2019 14:42:05 +0000") References: Message-ID: <87lfs3g8xi.fsf@oldenburg2.str.redhat.com> * Matthias Baesken: > For "-Wl,-z,now" some startup performance hits are mentioned in > articles/blogs - any experiences / performance-measurements with this > in the OpenJDK context ? While libjvm.so needs a staggering amount of relocations, most of them are relative. They are not eligible for lazy binding, and they have to be performed at startup even without BIND_NOW. That being said, relocation processing for libjvm.so adds a couple of milliseconds to startup, and it looks like their number is growing with each release. Thanks, Florian From mandy.chung at oracle.com Mon Nov 25 18:52:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Nov 2019 10:52:38 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: On 11/22/19 1:30 PM, Vicente Romero wrote: > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ make/lib/Lib-jdk.pack.gmk should be removed. make/scripts/compare_exceptions.sh.incl ??? Should ./lib/libunpack.so also be removed? make/scripts/compare.sh ??? line 535-543 invokes unpack200.?? You should get the advice from the build team what to be done with this file (or file a JBS issue as a follow-up) Mandy From claes.redestad at oracle.com Mon Nov 25 23:15:35 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 Nov 2019 00:15:35 +0100 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: <87lfs3g8xi.fsf@oldenburg2.str.redhat.com> References: <87lfs3g8xi.fsf@oldenburg2.str.redhat.com> Message-ID: <2473425f-bec7-540c-476e-f777da04d97f@oracle.com> On 2019-11-25 18:30, Florian Weimer wrote: > That being said, relocation processing for libjvm.so adds a couple of > milliseconds to startup, and it looks like their number is growing with > each release. This piqued my interest, so I took a quick look: readelf --relocs libjvm.so | wc -l 8: 85635 9: 112645 11: 105607 13: 107912 jdk/jdk: 106175 9 saw a big jump, yes, but things look pretty stable since, even improving a bit (various cleanups and feature removals..?). Of course improvements in this area would be most welcome (not an area I've been paying attention to - maybe I should?) Thanks! /Claes From weijun.wang at oracle.com Tue Nov 26 00:42:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 Nov 2019 08:42:38 +0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> Message-ID: <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> > On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: > > Build change looks good. Thanks. One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? I copied everything from CLDR_GEN_DONE but that one does not log anything actually. I can remove all output too, not really important. Thanks, Max > > /Erik > > On 2019-11-22 18:59, Weijun Wang wrote: >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ >> >> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. >> >> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. >> >> Other smaller changes made to FieldGen.jsh: >> >> 1. Package name >> 2. No more jshell, but now Java >> 3. Input/output paths as args for main() >> 4. White spaces, wrapping and indentation >> >> Thanks, >> Max >> From fweimer at redhat.com Tue Nov 26 08:51:25 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 26 Nov 2019 09:51:25 +0100 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: <2473425f-bec7-540c-476e-f777da04d97f@oracle.com> (Claes Redestad's message of "Tue, 26 Nov 2019 00:15:35 +0100") References: <87lfs3g8xi.fsf@oldenburg2.str.redhat.com> <2473425f-bec7-540c-476e-f777da04d97f@oracle.com> Message-ID: <877e3ndnqq.fsf@oldenburg2.str.redhat.com> * Claes Redestad: > On 2019-11-25 18:30, Florian Weimer wrote: >> That being said, relocation processing for libjvm.so adds a couple of >> milliseconds to startup, and it looks like their number is growing with >> each release. > > This piqued my interest, so I took a quick look: > > readelf --relocs libjvm.so | wc -l > > 8: 85635 > 9: 112645 > 11: 105607 > 13: 107912 > jdk/jdk: 106175 > > 9 saw a big jump, yes, but things look pretty stable since, even > improving a bit (various cleanups and feature removals..?). I see slightly higher numbers with the default build flags. The recent drop by ~1000 relocations is due to the CMS removal. > Of course improvements in this area would be most welcome (not an area > I've been paying attention to - maybe I should?) Unfortunately, I'm not aware of a good tool to gather relocation statistics with a goal towards avoiding them. Some cases may be easy changes (e.g., rewriting arrays of character strings). I suspect that quite a bit is related to C++ vtables. Thanks, Florian From christoph.goettschkes at microdoc.com Tue Nov 26 09:05:25 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Tue, 26 Nov 2019 10:05:25 +0100 Subject: RFR: 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <82089f9b-ba48-5fc2-b485-3b17997663de@oracle.com> References: <20191120182355.20831DDD26@aojmv0009> <82089f9b-ba48-5fc2-b485-3b17997663de@oracle.com> Message-ID: Hi Erik, thanks for looking into this. I created a new webrev which includes the changeset and you as a reviewer: http://cr.openjdk.java.net/~cgo/8234535/webrev.02/ Could you please sponsor this changeset and commit it into the repository for me? Thanks, Christoph Erik Joelsson wrote on 2019-11-22 17:19:08: > From: Erik Joelsson > To: christoph.goettschkes at microdoc.com, build-dev at openjdk.java.net > Date: 2019-11-22 17:19 > Subject: Re: RFR: 8234535: Cross compilation fails due to missing > CFLAGS for the BUILD_CC > > Hello Christoph, > > On 2019-11-20 10:22, christoph.goettschkes at microdoc.com wrote: > > Hi, > > > > please review the following change. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 > > Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev.00/ > > > > The removed lines are completely out of place and have no use at all. for > > the CC variable, for instance, the script does the following: > > > > CC_OLD="$CC" > > CC="$BUILD_CC" > > CC="$CC_OLD" > > > > without executing any function between those lines. I think that, while > > restructuring the build system, those lines have been copied to the wrong > > location. I copied them around the "FLAGS_SETUP_CFLAGS_CPU_DEP" call for > > the BUILD_CC, in order to make configure not use the target CFLAGS while > > discovering possible CFLAGS for the BUILD_CC, which was happening in our > > case. > Wow, I had not noticed that. Your fix looks correct. > > I am also not sure if the variable BUILD_CC_DISABLE_WARNING_PREFIX is > > actually used anywhere. I could not find any user and it might be possible > > to simply remove it. > It's used to override DISABLE_WARNING_PREFIX in buildjdk-spec.gmk so I > think it serves a purpose, even if we don't actually support different > toolchain types for cross and native compiler. If we ever will, then > this variable will be needed, so I think it should stay. > > I tried the change and compiled on an amd64 linux machine for amd64, and > > cross-compiled for linux on armv7 and linux on aarch64. I don't have > > access to other cross-compilation environments and would like to ask > > others to review and try out the change. > > I applied the patch and tried a few of our configurations. Since we use > the same (or close to the same) compiler versions across architectures, > I don't actually see any difference in the generated spec files. The > reason you see this is the large version difference between your compilers. > > Looks good, thanks for finding and fixing this! > > /Erik > > > Thanks, > > Christoph > > > From matthias.baesken at sap.com Tue Nov 26 09:19:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 09:19:13 +0000 Subject: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings Message-ID: Hello, here is a small adjustment that uses the typealias for NSTextInputSourceIdentifier . This fixes the build on macOS < 10.13 . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234795 http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/ Thanks, Matthias > > If there is a simple fix, I would very much like to see it done. I'm not > familiar enough with this area to know what the implications would be > though. > > /Erik > > On 2019-11-25 04:48, Baesken, Matthias wrote: > > Hello, any comments on the issue ? > > > > Could we maybe switch from using > > > > NSTextInputSourceIdentifier > > > > to > > > > String (NSString* ?) , because > https://developer.apple.com/documentation/appkit/nstextinputsourceiden > tifier > > > > says NSTextInputSourceIdentifier is a typealias for String ? > > > > Best regards ,Matthias > > > > > > > > > > Hello, I noticed that since today our jdk/jdk build fails on macOS . We run > it on macOS 10.12 . > > > > It seems > > https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > > > > 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java > ignores system settings > > > > Brought a dependency on 10.13. Was that intended ? Could we keep 10.12 > compatibility ? > > At least the doc of NSTextInputSourceIdentifier : > https://developer.apple.com/documentation/appkit/nstextinputsourceiden > tifier > > mentions macOS 10.13+ . > > > > > > > > Build errors are : > > ---------------------------- > > > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: > error: unknown type name 'NSTextInputSourceIdentifier' > > NSTextInputSourceIdentifier kbdLayout; > > ^ > > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: > error: assignment to readonly property > > self.cglLayer = windowLayer; > > ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ > > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1 > 9: error: assignment to readonly property > > self.cglLayer = nil; > > ~~~~~~~~~~~~~ ^ ~~~ > > 3 errors generated. > > > > > > ... > > > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45 > 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' (aka > 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] > > BOOL mouseIsOver = [[window contentView] mouseIsOver]; > > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 2 errors generated. > > > > > > > > Best regards, Matthias From prasanta.sadhukhan at oracle.com Tue Nov 26 09:26:13 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 26 Nov 2019 14:56:13 +0530 Subject: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: Message-ID: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> I have already raised a similar fix sometime back for JDK-8234786 Regards Prasanta On 26-Nov-19 2:49 PM, Baesken, Matthias wrote: > Hello, here is a small adjustment that uses the typealias for NSTextInputSourceIdentifier . This fixes the build on macOS < 10.13 . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8234795 > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/ > > > Thanks, Matthias > > >> If there is a simple fix, I would very much like to see it done. I'm not >> familiar enough with this area to know what the implications would be >> though. >> >> /Erik >> >> On 2019-11-25 04:48, Baesken, Matthias wrote: >>> Hello, any comments on the issue ? >>> >>> Could we maybe switch from using >>> >>> NSTextInputSourceIdentifier >>> >>> to >>> >>> String (NSString* ?) , because >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden >> tifier >>> says NSTextInputSourceIdentifier is a typealias for String ? >>> >>> Best regards ,Matthias >>> >>> >>> >>> >>> Hello, I noticed that since today our jdk/jdk build fails on macOS . We run >> it on macOS 10.12 . >>> It seems >>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 >>> >>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java >> ignores system settings >>> Brought a dependency on 10.13. Was that intended ? Could we keep 10.12 >> compatibility ? >>> At least the doc of NSTextInputSourceIdentifier : >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden >> tifier >>> mentions macOS 10.13+ . >>> >>> >>> >>> Build errors are : >>> ---------------------------- >>> >>> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: >> error: unknown type name 'NSTextInputSourceIdentifier' >>> NSTextInputSourceIdentifier kbdLayout; >>> ^ >>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: >> error: assignment to readonly property >>> self.cglLayer = windowLayer; >>> ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ >>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1 >> 9: error: assignment to readonly property >>> self.cglLayer = nil; >>> ~~~~~~~~~~~~~ ^ ~~~ >>> 3 errors generated. >>> >>> >>> ... >>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45 >> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' (aka >> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] >>> BOOL mouseIsOver = [[window contentView] mouseIsOver]; >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 2 errors generated. >>> >>> >>> >>> Best regards, Matthias From goetz.lindenmaier at sap.com Tue Nov 26 10:10:04 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Nov 2019 10:10:04 +0000 Subject: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> References: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> Message-ID: Hi Matthias, the change looks good. Thanks for fixing this. Best regards, Goetz. > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Dienstag, 26. November 2019 10:26 > To: Baesken, Matthias ; Erik Joelsson > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: 2d-dev at openjdk.java.net; Lindenmaier, Goetz > > Subject: Re: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after > 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with > backslashes on macOS/JIS keyboard: Java ignores system settings > > I have already raised a similar fix sometime back for JDK-8234786 > > Regards > > Prasanta > > On 26-Nov-19 2:49 PM, Baesken, Matthias wrote: > > Hello, here is a small adjustment that uses the typealias for > NSTextInputSourceIdentifier . This fixes the build on macOS < 10.13 . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8234795 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/ > > > > > > Thanks, Matthias > > > > > >> If there is a simple fix, I would very much like to see it done. I'm not > >> familiar enough with this area to know what the implications would be > >> though. > >> > >> /Erik > >> > >> On 2019-11-25 04:48, Baesken, Matthias wrote: > >>> Hello, any comments on the issue ? > >>> > >>> Could we maybe switch from using > >>> > >>> NSTextInputSourceIdentifier > >>> > >>> to > >>> > >>> String (NSString* ?) , because > >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden > >> tifier > >>> says NSTextInputSourceIdentifier is a typealias for String ? > >>> > >>> Best regards ,Matthias > >>> > >>> > >>> > >>> > >>> Hello, I noticed that since today our jdk/jdk build fails on macOS . We run > >> it on macOS 10.12 . > >>> It seems > >>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > >>> > >>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java > >> ignores system settings > >>> Brought a dependency on 10.13. Was that intended ? Could we keep > 10.12 > >> compatibility ? > >>> At least the doc of NSTextInputSourceIdentifier : > >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden > >> tifier > >>> mentions macOS 10.13+ . > >>> > >>> > >>> > >>> Build errors are : > >>> ---------------------------- > >>> > >>> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: > >> error: unknown type name 'NSTextInputSourceIdentifier' > >>> NSTextInputSourceIdentifier kbdLayout; > >>> ^ > >>> > >> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: > >> error: assignment to readonly property > >>> self.cglLayer = windowLayer; > >>> ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ > >>> > >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1 > >> 9: error: assignment to readonly property > >>> self.cglLayer = nil; > >>> ~~~~~~~~~~~~~ ^ ~~~ > >>> 3 errors generated. > >>> > >>> > >>> ... > >>> > >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45 > >> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' > (aka > >> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] > >>> BOOL mouseIsOver = [[window contentView] mouseIsOver]; > >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> 2 errors generated. > >>> > >>> > >>> > >>> Best regards, Matthias From martin.doerr at sap.com Tue Nov 26 10:43:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 26 Nov 2019 10:43:51 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hi Matthias and Erik, I also think this is an interesting option. I like the idea to generate smaller libraries. In addition to that, I could also imagine building with -Os (size optimized) by default and only select -O3 for performance critical files (e.g. C2's register allocation, some gc code, ...). If we want to go into such a direction for all linux platforms and want to use this s390 only change as some kind of pipe cleaner, I think this change is fine and can get pushed. Otherwise, I think building s390 differently and not intending to do the same for other linux platforms would be not so good. We should only make sure the exported symbols are set up properly to avoid that this optimization throws out too much. My 50 Cents. Best regards, Martin > -----Original Message----- > From: build-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 22. November 2019 16:01 > To: Erik Joelsson ; 'build-dev at openjdk.java.net' > ; core-libs-dev at openjdk.java.net > Subject: RE: RFR: 8234525: enable link-time section-gc for linux > s390x to remove unused code > > Hi Erik, > yes it makes the build more chatty - > our linux s390 product build log of jdk/jdk goes from ~ 60.000 lines to ~ > 123.000 lines with the patch. > > However the change is linux s390 only so I guess it will not disturb other > people ( in case we bring it to more platforms later on, we could remove the > printing or make it configurable ). > > Additionally the "chatty" output is used currently for eliminating unused > functions + data cross-platform > (see for example https://bugs.openjdk.java.net/browse/JDK-8234629 ). > > Best regards, Matthias > > > > > > > Hello Matthias, > > > > This looks like an interesting change. If you want to enable this for > > s390x, I'm ok with it. If it works out well, perhaps we can find a way > > to expand this to other architectures. > > > > Do you really want to set --print-gc-sections by default? I would assume > > that makes the build quite chatty. > > > > /Erik > > > > On 2019-11-21 00:54, Baesken, Matthias wrote: > > > Hello, > > > > > > gcc and ld can be instructed to work together to "garbage collect" unused > > input sections. > > > This feature eliminates unused code from native libraries. As a > prerequisite > > to take full advantage of the feature, > > > the source files need to be compiled with "-ffunction-sections -fdata- > > sections". > > > > > > Details on what happens can be found in the ld documentation: > > https://linux.die.net/man/1/ld . > > > See the description of --gc-sections and --print-gc-sections therein. > > > For more detailed insights there is a talk available from ELC2010: > > https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf > > > > > > My change enables the unused code elimination on linux s390x . > > > (on the other Linux platforms, there are still issues to be solved with the > > serviceability agent, but we do not have the serviceability agent on linux > > s390x). > > > > > > The change has 2 benefits : > > > - native libs with unused code get smaller (some get alot smaller) > > > some example lib sizes from linuxs390x (product build) : > > > default settings / link-time gc-sections > > > libmlib_image.so 556K 536K > > > libjavajpeg.so 300K 292K > > > libsplashscreen.so 412K 268K > > > libfontmanager.so 1.4M 864K > > > libjvm.so 19M 17M > > > > > > - the flag --print-gc-sections outputs the removed sections when calling > > the linker; > > > this helps a lot to find coding "waiting for" cross-platform removal. > > > > > > > > > Here is an example output of --print-gc-sections for the libnet-build (linux > > s390x) : > > > > > > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file > > '/builddir/support/native/java.base/libnet/DefaultProxySelector.o' <--- > > seems to be dead > > > /bin/ld: Removing unused section '.text.NET_ReadV' in file > > '/builddir/support/native/java.base/libnet/linux_close.o' <--- > seems > > to be dead, I requested cross-platform removal with > > https://bugs.openjdk.java.net/browse/JDK-8234501 > > > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' > in > > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to > be > > dead > > > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in > > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to > be > > dead > > > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in > file > > '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be > > dead > > > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems > to > > be dead indeed > > > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems > to > > be dead indeed > > > /bin/ld: Removing unused section '.text.kernelIsV24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > > seems to be dead indeed > > > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > used > > in getDefaultScopeID , which is dead > > > /bin/ld: Removing unused section '.bss.ni_class.8721' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > > used in getDefaultScopeID , which is dead > > > /bin/ld: Removing unused section '.bss.vinit24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > > only used in kernelIsV24 which is dead > > > /bin/ld: Removing unused section '.bss.kernelV24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > only > > used in kernelIsV24 which is dead > > > > > > bug/webrev : > > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/ > > > > > > Thanks, Matthias > > > > > > From matthias.baesken at sap.com Tue Nov 26 12:25:50 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 12:25:50 +0000 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: <6de2e634-eace-68c6-c86c-f0e51474745b@oracle.com> References: <6de2e634-eace-68c6-c86c-f0e51474745b@oracle.com> Message-ID: > I would involve at least hotspot-dev for a wider discussion on this as libjvm is > the most affected library. Hello Erik, Florian , currently relro is set already for libjvm. I think if this works nicely for libjvm, it shouldn't do any harm to set it as well in the BASIC_LDFLAGS for other binaries . I would propose a patch like : diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4 --- a/make/autoconf/flags-ldflags.m4 Fri Nov 22 09:06:35 2019 -0500 +++ b/make/autoconf/flags-ldflags.m4 Tue Nov 26 13:05:42 2019 +0100 @@ -70,10 +70,9 @@ fi # Add -z defs, to forbid undefined symbols in object files. - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" - - BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" - + # add relro (mark relocations read only) for all libs + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro" + BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1" If I understand https://bugzilla.redhat.com/show_bug.cgi?id=1571359 correct, RedHat is setting those flags already via the build system . Regarding "bindnow" (ld -z now) , this might be set additionally by using --with-extra-ldflags . Best regards, Matthias > Hello, > > I wasn't directly involved in introducing these flags, but my > understanding is that it's always a performance compromise. I would > involve at least hotspot-dev for a wider discussion on this as libjvm is > the most affected library. > > /Erik > > On 2019-11-25 06:42, Baesken, Matthias wrote: > > Hello, I wonder why the binary hardening on linux using Relocation > Read-Only (relro) is not enabled by default. > > > > Some info can be found here : > > > > https://wiki.debian.org/Hardening > > > > https://www.redhat.com/en/blog/hardening-elf-binaries-using- > relocation-read-only-relro > > > > > > Currently I notice the settings only for debug / fastdebug builds , see > flags-ldflags.m4 : > > > > # Setup debug level-dependent LDFLAGS > > if test "x$TOOLCHAIN_TYPE" = xgcc; then > > if test "x$OPENJDK_TARGET_OS" = xlinux; then > > if test x$DEBUG_LEVEL = xrelease; then > > > DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY - > Wl,-O1" > > else > > # mark relocations read only on (fast/slow) debug builds > > DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" > > fi > > if test x$DEBUG_LEVEL = xslowdebug; then > > # do relocations at load > > DEBUGLEVEL_LDFLAGS="-Wl,-z,now" > > fi > > fi > > > > Shouldn't we use at least "-Wl,-z,relro" also on product builds ? > > > > For "-Wl,-z,now" some startup performance hits are mentioned in > articles/blogs - any experiences / performance-measurements with this in > the OpenJDK context ? > > > > Best regards, Matthias > > From matthias.baesken at sap.com Tue Nov 26 12:39:11 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 12:39:11 +0000 Subject: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> References: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> Message-ID: Thanks for the update on this . Do you plan to push it today or tomorrow ? Best regards, Matthias > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Dienstag, 26. November 2019 10:26 > To: Baesken, Matthias ; Erik Joelsson > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: 2d-dev at openjdk.java.net; Lindenmaier, Goetz > > Subject: Re: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after > 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with > backslashes on macOS/JIS keyboard: Java ignores system settings > > I have already raised a similar fix sometime back for JDK-8234786 > > Regards > > Prasanta > > On 26-Nov-19 2:49 PM, Baesken, Matthias wrote: > > Hello, here is a small adjustment that uses the typealias for > NSTextInputSourceIdentifier . This fixes the build on macOS < 10.13 . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8234795 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/ > > > > > > Thanks, Matthias > > > > > >> If there is a simple fix, I would very much like to see it done. I'm not > >> familiar enough with this area to know what the implications would be > >> though. > >> > >> /Erik > >> > >> On 2019-11-25 04:48, Baesken, Matthias wrote: > >>> Hello, any comments on the issue ? > >>> > >>> Could we maybe switch from using > >>> > >>> NSTextInputSourceIdentifier > >>> > >>> to > >>> > >>> String (NSString* ?) , because > >> > https://developer.apple.com/documentation/appkit/nstextinputsourceiden > >> tifier > >>> says NSTextInputSourceIdentifier is a typealias for String ? > >>> > >>> Best regards ,Matthias > >>> > >>> > >>> > >>> > >>> Hello, I noticed that since today our jdk/jdk build fails on macOS . We > run > >> it on macOS 10.12 . > >>> It seems > >>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 > >>> > >>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: > Java > >> ignores system settings > >>> Brought a dependency on 10.13. Was that intended ? Could we keep > 10.12 > >> compatibility ? > >>> At least the doc of NSTextInputSourceIdentifier : > >> > https://developer.apple.com/documentation/appkit/nstextinputsourceiden > >> tifier > >>> mentions macOS 10.13+ . > >>> > >>> > >>> > >>> Build errors are : > >>> ---------------------------- > >>> > >>> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: > >> error: unknown type name 'NSTextInputSourceIdentifier' > >>> NSTextInputSourceIdentifier kbdLayout; > >>> ^ > >>> > >> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: > >> error: assignment to readonly property > >>> self.cglLayer = windowLayer; > >>> ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ > >>> > >> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1 > >> 9: error: assignment to readonly property > >>> self.cglLayer = nil; > >>> ~~~~~~~~~~~~~ ^ ~~~ > >>> 3 errors generated. > >>> > >>> > >>> ... > >>> > >> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45 > >> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' > (aka > >> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] > >>> BOOL mouseIsOver = [[window contentView] mouseIsOver]; > >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> 2 errors generated. > >>> > >>> > >>> > >>> Best regards, Matthias From matthias.baesken at sap.com Tue Nov 26 12:53:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 12:53:07 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hi Martin , > Hi Matthias and Erik, > > I also think this is an interesting option. > > I like the idea to generate smaller libraries. In addition to that, I could also > imagine building with -Os (size optimized) by default and only select -O3 for > performance critical files (e.g. C2's register allocation, some gc code, ...). > This is a good idea . However I would like to look into this separately in another change . ( Maybe there should also be a configure setting to select for size vs. speed optimization ) > If we want to go into such a direction for all linux platforms and want to use > this s390 only change as some kind of pipe cleaner, I think this change is fine > and can get pushed. Yes , that was my intention. Erik, may I add you as a reviewer too ? Best regards, Matthias > Otherwise, I think building s390 differently and not intending to do the same > for other linux platforms would be not so good. > > We should only make sure the exported symbols are set up properly to avoid > that this optimization throws out too much. > > My 50 Cents. > > Best regards, > Martin > From matthias.baesken at sap.com Tue Nov 26 13:07:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 13:07:46 +0000 Subject: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro) Message-ID: > Hello Erik, Florian , currently relro is set already for libjvm. > I think if this works nicely for libjvm, it shouldn't do any harm to set it as well > in the BASIC_LDFLAGS for other binaries . > I would propose a patch like : Hello, here is my webrev , please review . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234809 http://cr.openjdk.java.net/~mbaesken/webrevs/8234809.0/ Thanks, Matthias > > > I would involve at least hotspot-dev for a wider discussion on this as libjvm > is > > the most affected library. > > Hello Erik, Florian , currently relro is set already for libjvm. > I think if this works nicely for libjvm, it shouldn't do any harm to set it as well > in the BASIC_LDFLAGS for other binaries . > I would propose a patch like : > > diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4 > --- a/make/autoconf/flags-ldflags.m4 Fri Nov 22 09:06:35 2019 -0500 > +++ b/make/autoconf/flags-ldflags.m4 Tue Nov 26 13:05:42 2019 +0100 > @@ -70,10 +70,9 @@ > fi > > # Add -z defs, to forbid undefined symbols in object files. > - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" > - > - BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" > - > + # add relro (mark relocations read only) for all libs > + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro" > + BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1" > > > If I understand > https://bugzilla.redhat.com/show_bug.cgi?id=1571359 > correct, RedHat is setting those flags already via the build system . > > Regarding "bindnow" (ld -z now) , this might be set additionally by using -- > with-extra-ldflags . > > > Best regards, Matthias > > > > Hello, > > > > I wasn't directly involved in introducing these flags, but my > > understanding is that it's always a performance compromise. I would > > involve at least hotspot-dev for a wider discussion on this as libjvm is > > the most affected library. > > > > /Erik > > > > On 2019-11-25 06:42, Baesken, Matthias wrote: > > > Hello, I wonder why the binary hardening on linux using Relocation > > Read-Only (relro) is not enabled by default. > > > > > > Some info can be found here : > > > > > > https://wiki.debian.org/Hardening > > > > > > https://www.redhat.com/en/blog/hardening-elf-binaries-using- > > relocation-read-only-relro > > > > > > > > > Currently I notice the settings only for debug / fastdebug builds , see > > flags-ldflags.m4 : > > > > > > # Setup debug level-dependent LDFLAGS > > > if test "x$TOOLCHAIN_TYPE" = xgcc; then > > > if test "x$OPENJDK_TARGET_OS" = xlinux; then > > > if test x$DEBUG_LEVEL = xrelease; then > > > > > DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY - > > Wl,-O1" > > > else > > > # mark relocations read only on (fast/slow) debug builds > > > DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" > > > fi > > > if test x$DEBUG_LEVEL = xslowdebug; then > > > # do relocations at load > > > DEBUGLEVEL_LDFLAGS="-Wl,-z,now" > > > fi > > > fi > > > > > > Shouldn't we use at least "-Wl,-z,relro" also on product builds ? > > > > > > For "-Wl,-z,now" some startup performance hits are mentioned in > > articles/blogs - any experiences / performance-measurements with this > in > > the OpenJDK context ? > > > > > > Best regards, Matthias > > > From fweimer at redhat.com Tue Nov 26 13:18:12 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 26 Nov 2019 14:18:12 +0100 Subject: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: (Matthias Baesken's message of "Tue, 26 Nov 2019 12:25:50 +0000") References: <6de2e634-eace-68c6-c86c-f0e51474745b@oracle.com> Message-ID: <87h82qdbe3.fsf@oldenburg2.str.redhat.com> * Matthias Baesken: > If I understand > https://bugzilla.redhat.com/show_bug.cgi?id=1571359 > correct, RedHat is setting those flags already via the build system . BFD ld in binutils defaults to relro, except perhaps on s390x where your version might not implement the partial RELRO variant that you get without -z now (BIND_NOW is not enabled by default). > Regarding "bindnow" (ld -z now) , this might be set additionally by > using --with-extra-ldflags . Yes, that is usually more controversial because it can have an impact on startup time. But even the AWT libraries have relatively few function references, so it probably does not matter. On the other hand, all this security hardening is typically not very effective because part of classes.jsa is mapped rwx at a fixed address, so you can just abuse that (if you want to inject machine code directly, I'm sure there are other options for bytecode). Thanks, Florian From erik.joelsson at oracle.com Tue Nov 26 16:14:47 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 08:14:47 -0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> Message-ID: <6f20a42b-4973-6a36-3f4c-0d834aee922d@oracle.com> On 2019-11-25 16:42, Weijun Wang wrote: > >> On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: >> >> Build change looks good. > Thanks. > > One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? No, we are not able to support different log levels to the main log file and console. What you can do is add $(LOG_INFO) or $(LOG_DEBUG) last on the command line. That macro resolves to "> /dev/null" when we don't want the output printed. How much output and how interesting is it to see? You can also wrap the whole command in a call to ExecuteWithLog to have it being logged to an individual file, which gets repeated at the end of the build in case it fails. I think you should be able to combine the two with something like this: $(call ExecuteWithLog, ...) $(LOG_DEBUG) That should print everything to the special log file as well as letting it pass to stdout when LOG=debug, but I haven't tested it. /Erik > I copied everything from CLDR_GEN_DONE but that one does not log anything actually. > > I can remove all output too, not really important. > > Thanks, > Max > >> /Erik >> >> On 2019-11-22 18:59, Weijun Wang wrote: >>> Please review the change at >>> >>> http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ >>> >>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. >>> >>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. >>> >>> Other smaller changes made to FieldGen.jsh: >>> >>> 1. Package name >>> 2. No more jshell, but now Java >>> 3. Input/output paths as args for main() >>> 4. White spaces, wrapping and indentation >>> >>> Thanks, >>> Max >>> From erik.joelsson at oracle.com Tue Nov 26 16:16:19 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 08:16:19 -0800 Subject: RFR: 8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC In-Reply-To: <2wh0mu8eyg-1@userp2030.oracle.com> References: <20191120182355.20831DDD26@aojmv0009> <82089f9b-ba48-5fc2-b485-3b17997663de@oracle.com> <2wh0mu8eyg-1@userp2030.oracle.com> Message-ID: <05597155-3fd5-6875-171d-837dc208dab5@oracle.com> Will do. /Erik On 2019-11-26 01:05, christoph.goettschkes at microdoc.com wrote: > Hi Erik, > > thanks for looking into this. I created a new webrev which includes the > changeset and you as a reviewer: > > http://cr.openjdk.java.net/~cgo/8234535/webrev.02/ > > Could you please sponsor this changeset and commit it into the repository > for me? > > Thanks, > Christoph > > Erik Joelsson wrote on 2019-11-22 17:19:08: > >> From: Erik Joelsson >> To: christoph.goettschkes at microdoc.com, build-dev at openjdk.java.net >> Date: 2019-11-22 17:19 >> Subject: Re: RFR: 8234535: Cross compilation fails due to missing >> CFLAGS for the BUILD_CC >> >> Hello Christoph, >> >> On 2019-11-20 10:22, christoph.goettschkes at microdoc.com wrote: >>> Hi, >>> >>> please review the following change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234535 >>> Webrev: https://cr.openjdk.java.net/~cgo/8234535/webrev.00/ >>> >>> The removed lines are completely out of place and have no use at all. > for >>> the CC variable, for instance, the script does the following: >>> >>> CC_OLD="$CC" >>> CC="$BUILD_CC" >>> CC="$CC_OLD" >>> >>> without executing any function between those lines. I think that, > while >>> restructuring the build system, those lines have been copied to the > wrong >>> location. I copied them around the "FLAGS_SETUP_CFLAGS_CPU_DEP" call > for >>> the BUILD_CC, in order to make configure not use the target CFLAGS > while >>> discovering possible CFLAGS for the BUILD_CC, which was happening in > our >>> case. >> Wow, I had not noticed that. Your fix looks correct. >>> I am also not sure if the variable BUILD_CC_DISABLE_WARNING_PREFIX is >>> actually used anywhere. I could not find any user and it might be > possible >>> to simply remove it. >> It's used to override DISABLE_WARNING_PREFIX in buildjdk-spec.gmk so I >> think it serves a purpose, even if we don't actually support different >> toolchain types for cross and native compiler. If we ever will, then >> this variable will be needed, so I think it should stay. >>> I tried the change and compiled on an amd64 linux machine for amd64, > and >>> cross-compiled for linux on armv7 and linux on aarch64. I don't have >>> access to other cross-compilation environments and would like to ask >>> others to review and try out the change. >> I applied the patch and tried a few of our configurations. Since we use >> the same (or close to the same) compiler versions across architectures, >> I don't actually see any difference in the generated spec files. The >> reason you see this is the large version difference between your > compilers. >> Looks good, thanks for finding and fixing this! >> >> /Erik >> >>> Thanks, >>> Christoph >>> From erik.joelsson at oracle.com Tue Nov 26 16:28:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 08:28:17 -0800 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: <17a27614-2ada-6929-6dc5-a2c8c4a2255d@oracle.com> On 2019-11-26 04:53, Baesken, Matthias wrote: > Erik, may I add you as a reviewer too ? Yes. /Erik From erik.joelsson at oracle.com Tue Nov 26 16:32:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 08:32:17 -0800 Subject: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: References: Message-ID: <8609df99-8798-fcef-45c1-cac89425f943@oracle.com> Looks good. /Erik On 2019-11-26 05:07, Baesken, Matthias wrote: >> Hello Erik, Florian , currently relro is set already for libjvm. >> I think if this works nicely for libjvm, it shouldn't do any harm to set it as well >> in the BASIC_LDFLAGS for other binaries . >> I would propose a patch like : > Hello, here is my webrev , please review . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8234809 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234809.0/ > > > Thanks, Matthias > >>> I would involve at least hotspot-dev for a wider discussion on this as libjvm >> is >>> the most affected library. >> Hello Erik, Florian , currently relro is set already for libjvm. >> I think if this works nicely for libjvm, it shouldn't do any harm to set it as well >> in the BASIC_LDFLAGS for other binaries . >> I would propose a patch like : >> >> diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4 >> --- a/make/autoconf/flags-ldflags.m4 Fri Nov 22 09:06:35 2019 -0500 >> +++ b/make/autoconf/flags-ldflags.m4 Tue Nov 26 13:05:42 2019 +0100 >> @@ -70,10 +70,9 @@ >> fi >> >> # Add -z defs, to forbid undefined symbols in object files. >> - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" >> - >> - BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" >> - >> + # add relro (mark relocations read only) for all libs >> + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro" >> + BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1" >> >> >> If I understand >> https://bugzilla.redhat.com/show_bug.cgi?id=1571359 >> correct, RedHat is setting those flags already via the build system . >> >> Regarding "bindnow" (ld -z now) , this might be set additionally by using -- >> with-extra-ldflags . >> >> >> Best regards, Matthias >> >> >>> Hello, >>> >>> I wasn't directly involved in introducing these flags, but my >>> understanding is that it's always a performance compromise. I would >>> involve at least hotspot-dev for a wider discussion on this as libjvm is >>> the most affected library. >>> >>> /Erik >>> >>> On 2019-11-25 06:42, Baesken, Matthias wrote: >>>> Hello, I wonder why the binary hardening on linux using Relocation >>> Read-Only (relro) is not enabled by default. >>>> Some info can be found here : >>>> >>>> https://wiki.debian.org/Hardening >>>> >>>> https://www.redhat.com/en/blog/hardening-elf-binaries-using- >>> relocation-read-only-relro >>>> >>>> Currently I notice the settings only for debug / fastdebug builds , see >>> flags-ldflags.m4 : >>>> # Setup debug level-dependent LDFLAGS >>>> if test "x$TOOLCHAIN_TYPE" = xgcc; then >>>> if test "x$OPENJDK_TARGET_OS" = xlinux; then >>>> if test x$DEBUG_LEVEL = xrelease; then >>>> >>> DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY - >>> Wl,-O1" >>>> else >>>> # mark relocations read only on (fast/slow) debug builds >>>> DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" >>>> fi >>>> if test x$DEBUG_LEVEL = xslowdebug; then >>>> # do relocations at load >>>> DEBUGLEVEL_LDFLAGS="-Wl,-z,now" >>>> fi >>>> fi >>>> >>>> Shouldn't we use at least "-Wl,-z,relro" also on product builds ? >>>> >>>> For "-Wl,-z,now" some startup performance hits are mentioned in >>> articles/blogs - any experiences / performance-measurements with this >> in >>> the OpenJDK context ? >>>> Best regards, Matthias >>>> From matthias.baesken at sap.com Tue Nov 26 17:00:28 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 17:00:28 +0000 Subject: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: <8609df99-8798-fcef-45c1-cac89425f943@oracle.com> References: <8609df99-8798-fcef-45c1-cac89425f943@oracle.com> Message-ID: Thanks ! Florian, may I add you as reviewer ? Best regards, Matthias > Looks good. > > /Erik > > On 2019-11-26 05:07, Baesken, Matthias wrote: > >> Hello Erik, Florian , currently relro is set already for libjvm. > >> I think if this works nicely for libjvm, it shouldn't do any harm to set it as > well > >> in the BASIC_LDFLAGS for other binaries . > >> I would propose a patch like : > > Hello, here is my webrev , please review . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8234809 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234809.0/ > > > > > > Thanks, Matthias > > > >>> I would involve at least hotspot-dev for a wider discussion on this as > libjvm > >> is > >>> the most affected library. > >> Hello Erik, Florian , currently relro is set already for libjvm. > >> I think if this works nicely for libjvm, it shouldn't do any harm to set it as > well > >> in the BASIC_LDFLAGS for other binaries . > >> I would propose a patch like : > >> > >> diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4 > >> --- a/make/autoconf/flags-ldflags.m4 Fri Nov 22 09:06:35 2019 -0500 > >> +++ b/make/autoconf/flags-ldflags.m4 Tue Nov 26 13:05:42 2019 +0100 > >> @@ -70,10 +70,9 @@ > >> fi > >> > >> # Add -z defs, to forbid undefined symbols in object files. > >> - BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs" > >> - > >> - BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro" > >> - > >> + # add relro (mark relocations read only) for all libs > >> + BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro" > >> + BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1" > >> > >> > >> If I understand > >> https://bugzilla.redhat.com/show_bug.cgi?id=1571359 > >> correct, RedHat is setting those flags already via the build system . > >> > >> Regarding "bindnow" (ld -z now) , this might be set additionally by > using -- > >> with-extra-ldflags . > >> > >> > >> Best regards, Matthias > >> > >> > >>> Hello, > >>> > >>> I wasn't directly involved in introducing these flags, but my > >>> understanding is that it's always a performance compromise. I would > >>> involve at least hotspot-dev for a wider discussion on this as libjvm is > >>> the most affected library. > >>> > >>> /Erik > >>> > >>> On 2019-11-25 06:42, Baesken, Matthias wrote: > >>>> Hello, I wonder why the binary hardening on linux using Relocation > >>> Read-Only (relro) is not enabled by default. > >>>> Some info can be found here : > >>>> > >>>> https://wiki.debian.org/Hardening > >>>> > >>>> https://www.redhat.com/en/blog/hardening-elf-binaries-using- > >>> relocation-read-only-relro > >>>> > >>>> Currently I notice the settings only for debug / fastdebug builds , see > >>> flags-ldflags.m4 : > >>>> # Setup debug level-dependent LDFLAGS > >>>> if test "x$TOOLCHAIN_TYPE" = xgcc; then > >>>> if test "x$OPENJDK_TARGET_OS" = xlinux; then > >>>> if test x$DEBUG_LEVEL = xrelease; then > >>>> > >>> > DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY - > >>> Wl,-O1" > >>>> else > >>>> # mark relocations read only on (fast/slow) debug builds > >>>> DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro" > >>>> fi > >>>> if test x$DEBUG_LEVEL = xslowdebug; then > >>>> # do relocations at load > >>>> DEBUGLEVEL_LDFLAGS="-Wl,-z,now" > >>>> fi > >>>> fi > >>>> > >>>> Shouldn't we use at least "-Wl,-z,relro" also on product builds ? > >>>> > >>>> For "-Wl,-z,now" some startup performance hits are mentioned in > >>> articles/blogs - any experiences / performance-measurements with > this > >> in > >>> the OpenJDK context ? > >>>> Best regards, Matthias > >>>> From fweimer at redhat.com Tue Nov 26 17:04:16 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 26 Nov 2019 18:04:16 +0100 Subject: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro) In-Reply-To: (Matthias Baesken's message of "Tue, 26 Nov 2019 17:00:28 +0000") References: <8609df99-8798-fcef-45c1-cac89425f943@oracle.com> Message-ID: <87blsybmcv.fsf@oldenburg2.str.redhat.com> * Matthias Baesken: > Florian, may I add you as reviewer ? Sure, but I don't have a formal reviewer role. Thanks, Florian From erik.joelsson at oracle.com Tue Nov 26 20:56:05 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 12:56:05 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> Message-ID: <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> (adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: > I posted new composite webrev [7], and git patch [8] after pushing fix > for JDK-8234402 [6]. > > [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ > > [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch > > /Andy > > On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >> I took the "git diff" patch [5] that you uploaded yesterday, applied >> it, and verified that it is the same as what is in the >> JDK-8200758-branch branch of the sandbox. It builds and runs fine for >> me. >> >> I ran jcheck and it found the following three files with whitespace >> errors that will need to be fixed before you push: >> >> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >> Trailing whitespace >> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >> Trailing whitespace >> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >> whitespace >> >> The second of these will go away with the fix for JDK-8234402 [6], so >> you don't need to do anything there. Once the fix for JDK-8234402 is >> pushed to sandbox, I presume you will update the webrev, right? >> >> Pending the fix for JDK-8234402 and the needed white-space fixes, >> this is a +1 from me (although I am not a jdk Project Reviewer, so >> you will need at least one review from someone who is). >> >> -- Kevin >> >> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >> >> >> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>> Please review? changes for [1] which is the implementation bug for >>> JEP-343. >>> >>> The webrev at [2] is the total cumulative webrev of changes for the >>> jpackage tool, currently in the JDK-8200758-branch branch of the >>> open sandbox repository. >>> >>> The webrev at [3] shows the changes since EA-06 (Build >>> 13-jpackage+1-49 ) up to the current point. >>> >>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>> >>> Please send feedback to core-libs-dev at openjdk.java.net >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>> >>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>> >>> [4] http://jdk.java.net/jpackage/ >>> >> From andy.herrick at oracle.com Tue Nov 26 20:56:32 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Nov 2019 15:56:32 -0500 Subject: Fwd: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> References: <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> Message-ID: Forwarding review thread to build-dev. /Andy -------- Forwarded Message -------- Subject: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation Date: Wed, 20 Nov 2019 12:37:20 -0500 From: Andy Herrick Organization: Oracle Corporation To: Kevin Rushforth , core-libs-dev I posted new composite webrev [7], and git patch [8] after pushing fix for JDK-8234402 [6]. [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch /Andy On 11/19/2019 3:13 PM, Kevin Rushforth wrote: > I took the "git diff" patch [5] that you uploaded yesterday, applied > it, and verified that it is the same as what is in the > JDK-8200758-branch branch of the sandbox. It builds and runs fine for me. > > I ran jcheck and it found the following three files with whitespace > errors that will need to be fixed before you push: > > src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: > Trailing whitespace > src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: > Trailing whitespace > test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing > whitespace > > The second of these will go away with the fix for JDK-8234402 [6], so > you don't need to do anything there. Once the fix for JDK-8234402 is > pushed to sandbox, I presume you will update the webrev, right? > > Pending the fix for JDK-8234402 and the needed white-space fixes, this > is a +1 from me (although I am not a jdk Project Reviewer, so you will > need at least one review from someone who is). > > -- Kevin > > [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch > [6] https://bugs.openjdk.java.net/browse/JDK-8234402 > > > On 11/13/2019 4:23 PM, Andy Herrick wrote: >> Please review? changes for [1] which is the implementation bug for >> JEP-343. >> >> The webrev at [2] is the total cumulative webrev of changes for the >> jpackage tool, currently in the JDK-8200758-branch branch of the open >> sandbox repository. >> >> The webrev at [3] shows the changes since EA-06 (Build >> 13-jpackage+1-49 ) up to the current point. >> >> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >> >> Please send feedback to core-libs-dev at openjdk.java.net >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >> >> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >> >> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >> >> [4] http://jdk.java.net/jpackage/ >> > From kevin.rushforth at oracle.com Tue Nov 26 21:36:39 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Nov 2019 13:36:39 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> Message-ID: <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> This all looks good. +1 -- Kevin On 11/26/2019 12:56 PM, Erik Joelsson wrote: > (adding build-dev) > > Build changes look good. > > /Erik > > On 2019-11-20 09:37, Andy Herrick wrote: >> I posted new composite webrev [7], and git patch [8] after pushing >> fix for JDK-8234402 [6]. >> >> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >> >> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >> >> /Andy >> >> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>> I took the "git diff" patch [5] that you uploaded yesterday, applied >>> it, and verified that it is the same as what is in the >>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>> for me. >>> >>> I ran jcheck and it found the following three files with whitespace >>> errors that will need to be fixed before you push: >>> >>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>> Trailing whitespace >>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>> Trailing whitespace >>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>> whitespace >>> >>> The second of these will go away with the fix for JDK-8234402 [6], >>> so you don't need to do anything there. Once the fix for JDK-8234402 >>> is pushed to sandbox, I presume you will update the webrev, right? >>> >>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>> you will need at least one review from someone who is). >>> >>> -- Kevin >>> >>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>> >>> >>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>> Please review? changes for [1] which is the implementation bug for >>>> JEP-343. >>>> >>>> The webrev at [2] is the total cumulative webrev of changes for the >>>> jpackage tool, currently in the JDK-8200758-branch branch of the >>>> open sandbox repository. >>>> >>>> The webrev at [3] shows the changes since EA-06 (Build >>>> 13-jpackage+1-49 ) up to the current point. >>>> >>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>> >>>> Please send feedback to core-libs-dev at openjdk.java.net >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>> >>>> [4] http://jdk.java.net/jpackage/ >>>> >>> From philip.race at oracle.com Tue Nov 26 21:53:55 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Nov 2019 13:53:55 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> Message-ID: <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Andy, I am puzzled by what I see here > The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 ) up to the current point. > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ This includes the JNLPConverter which isn't what I expected to see and (correctly) isn't in the cumulative webrev .... Since [3] seemed like the most obvious thing to do a review of the recent changes I'd like to be sure it has the correct content and I am not sure it does ... -phil. On 11/26/19 1:36 PM, Kevin Rushforth wrote: > This all looks good. > > +1 > > -- Kevin > > > On 11/26/2019 12:56 PM, Erik Joelsson wrote: >> (adding build-dev) >> >> Build changes look good. >> >> /Erik >> >> On 2019-11-20 09:37, Andy Herrick wrote: >>> I posted new composite webrev [7], and git patch [8] after pushing >>> fix for JDK-8234402 [6]. >>> >>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>> >>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>> >>> /Andy >>> >>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>> applied it, and verified that it is the same as what is in the >>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>> for me. >>>> >>>> I ran jcheck and it found the following three files with whitespace >>>> errors that will need to be fixed before you push: >>>> >>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>> Trailing whitespace >>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>> Trailing whitespace >>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>> whitespace >>>> >>>> The second of these will go away with the fix for JDK-8234402 [6], >>>> so you don't need to do anything there. Once the fix for >>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>> webrev, right? >>>> >>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>>> you will need at least one review from someone who is). >>>> >>>> -- Kevin >>>> >>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>> >>>> >>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>> Please review? changes for [1] which is the implementation bug for >>>>> JEP-343. >>>>> >>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>> the open sandbox repository. >>>>> >>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>> 13-jpackage+1-49 ) up to the current point. >>>>> >>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>> >>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>> >>>>> [4] http://jdk.java.net/jpackage/ >>>>> >>>> > From andy.herrick at oracle.com Tue Nov 26 22:17:18 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Nov 2019 17:17:18 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Message-ID: yes,? this incremental webrev contains the JNLPConverter code, which it should not. I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. /Andy On 11/26/2019 4:53 PM, Phil Race wrote: > Andy, > > I am puzzled by what I see here > > The webrev at [3] shows the changes since EA-06 (Build > 13-jpackage+1-49 ) up to the current point. > > > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ > > This includes the JNLPConverter which isn't what I expected to see and > (correctly) isn't in the cumulative webrev .... > > Since [3] seemed like the most obvious thing to do a review of the recent > changes I'd like to be sure it has the correct content and I am not > sure it does ... > > -phil. > > On 11/26/19 1:36 PM, Kevin Rushforth wrote: >> This all looks good. >> >> +1 >> >> -- Kevin >> >> >> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>> (adding build-dev) >>> >>> Build changes look good. >>> >>> /Erik >>> >>> On 2019-11-20 09:37, Andy Herrick wrote: >>>> I posted new composite webrev [7], and git patch [8] after pushing >>>> fix for JDK-8234402 [6]. >>>> >>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>> >>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>> >>>> /Andy >>>> >>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>> applied it, and verified that it is the same as what is in the >>>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>>> for me. >>>>> >>>>> I ran jcheck and it found the following three files with >>>>> whitespace errors that will need to be fixed before you push: >>>>> >>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>> Trailing whitespace >>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>> Trailing whitespace >>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>> whitespace >>>>> >>>>> The second of these will go away with the fix for JDK-8234402 [6], >>>>> so you don't need to do anything there. Once the fix for >>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>> webrev, right? >>>>> >>>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>>>> you will need at least one review from someone who is). >>>>> >>>>> -- Kevin >>>>> >>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>> >>>>> >>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>> Please review? changes for [1] which is the implementation bug >>>>>> for JEP-343. >>>>>> >>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>>> the open sandbox repository. >>>>>> >>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>> >>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>> >>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>> >>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>> >>>>>> [4] http://jdk.java.net/jpackage/ >>>>>> >>>>> >> > From weijun.wang at oracle.com Wed Nov 27 00:39:00 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Nov 2019 08:39:00 +0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: <6f20a42b-4973-6a36-3f4c-0d834aee922d@oracle.com> References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> <6f20a42b-4973-6a36-3f4c-0d834aee922d@oracle.com> Message-ID: > On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote: > > On 2019-11-25 16:42, Weijun Wang wrote: >> >>> On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: >>> >>> Build change looks good. >> Thanks. >> >> One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? > > No, we are not able to support different log levels to the main log file and console. What you can do is add $(LOG_INFO) or $(LOG_DEBUG) last on the command line. That macro resolves to "> /dev/null" when we don't want the output printed. How much output and how interesting is it to see? You can also wrap the whole command in a call to ExecuteWithLog to have it being logged to an individual file, which gets repeated at the end of the build in case it fails. > > I think you should be able to combine the two with something like this: > > $(call ExecuteWithLog, ...) $(LOG_DEBUG) > > That should print everything to the special log file as well as letting it pass to stdout when LOG=debug, but I haven't tested it. The log shows on the console with LOG=debug but whatever LOG level I choose, the output is always collected in the log file. This is exactly what I am looking for. Thanks, Max > > /Erik > >> I copied everything from CLDR_GEN_DONE but that one does not log anything actually. >> >> I can remove all output too, not really important. >> >> Thanks, >> Max >> >>> /Erik >>> >>> On 2019-11-22 18:59, Weijun Wang wrote: >>>> Please review the change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ >>>> >>>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. >>>> >>>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. >>>> >>>> Other smaller changes made to FieldGen.jsh: >>>> >>>> 1. Package name >>>> 2. No more jshell, but now Java >>>> 3. Input/output paths as args for main() >>>> 4. White spaces, wrapping and indentation >>>> >>>> Thanks, >>>> Max >>>> From philip.race at oracle.com Wed Nov 27 02:01:29 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 26 Nov 2019 18:01:29 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Message-ID: <5DDDD8F9.3060906@oracle.com> > I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. It is also not very incremental. * *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java is definitely not "new" ... -phil. On 11/26/19, 2:17 PM, Andy Herrick wrote: > yes, this incremental webrev contains the JNLPConverter code, which > it should not. > > I believe otherwise it is an accurate incremental webrev of the > jpackage changes since EA-5. > > /Andy > > On 11/26/2019 4:53 PM, Phil Race wrote: >> Andy, >> >> I am puzzled by what I see here >> > The webrev at [3] shows the changes since EA-06 (Build >> 13-jpackage+1-49 ) up to the current point. >> >> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >> >> This includes the JNLPConverter which isn't what I expected to see and >> (correctly) isn't in the cumulative webrev .... >> >> Since [3] seemed like the most obvious thing to do a review of the >> recent >> changes I'd like to be sure it has the correct content and I am not >> sure it does ... >> >> -phil. >> >> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>> This all looks good. >>> >>> +1 >>> >>> -- Kevin >>> >>> >>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>> (adding build-dev) >>>> >>>> Build changes look good. >>>> >>>> /Erik >>>> >>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>> I posted new composite webrev [7], and git patch [8] after pushing >>>>> fix for JDK-8234402 [6]. >>>>> >>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>> >>>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>> >>>>> /Andy >>>>> >>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>> applied it, and verified that it is the same as what is in the >>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>>>> for me. >>>>>> >>>>>> I ran jcheck and it found the following three files with >>>>>> whitespace errors that will need to be fixed before you push: >>>>>> >>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>> Trailing whitespace >>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>> Trailing whitespace >>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>>> whitespace >>>>>> >>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>>> webrev, right? >>>>>> >>>>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>>>> this is a +1 from me (although I am not a jdk Project Reviewer, >>>>>> so you will need at least one review from someone who is). >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>> >>>>>> >>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>> Please review changes for [1] which is the implementation bug >>>>>>> for JEP-343. >>>>>>> >>>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>>>> the open sandbox repository. >>>>>>> >>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>> >>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>> >>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>> >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>> >>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>> >>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>> >>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>> >>>>>> >>> >> From prasanta.sadhukhan at oracle.com Wed Nov 27 08:07:22 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Nov 2019 13:37:22 +0530 Subject: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings In-Reply-To: References: <72f5a189-50a3-6eaf-b356-1feb0750c0a5@oracle.com> Message-ID: The fix is pushed in jdk/client, after pre-integration-testing (PIT) is done, it will be propagated to jdk/jdk. Regards Prasanta On 26-Nov-19 6:09 PM, Baesken, Matthias wrote: > Thanks for the update on this . > Do you plan to push it today or tomorrow ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Prasanta Sadhukhan >> Sent: Dienstag, 26. November 2019 10:26 >> To: Baesken, Matthias ; Erik Joelsson >> ; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Cc: 2d-dev at openjdk.java.net; Lindenmaier, Goetz >> >> Subject: Re: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after >> 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with >> backslashes on macOS/JIS keyboard: Java ignores system settings >> >> I have already raised a similar fix sometime back for JDK-8234786 >> >> Regards >> >> Prasanta >> >> On 26-Nov-19 2:49 PM, Baesken, Matthias wrote: >>> Hello, here is a small adjustment that uses the typealias for >> NSTextInputSourceIdentifier . This fixes the build on macOS < 10.13 . >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8234795 >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/ >>> >>> >>> Thanks, Matthias >>> >>> >>>> If there is a simple fix, I would very much like to see it done. I'm not >>>> familiar enough with this area to know what the implications would be >>>> though. >>>> >>>> /Erik >>>> >>>> On 2019-11-25 04:48, Baesken, Matthias wrote: >>>>> Hello, any comments on the issue ? >>>>> >>>>> Could we maybe switch from using >>>>> >>>>> NSTextInputSourceIdentifier >>>>> >>>>> to >>>>> >>>>> String (NSString* ?) , because >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden >>>> tifier >>>>> says NSTextInputSourceIdentifier is a typealias for String ? >>>>> >>>>> Best regards ,Matthias >>>>> >>>>> >>>>> >>>>> >>>>> Hello, I noticed that since today our jdk/jdk build fails on macOS . We >> run >>>> it on macOS 10.12 . >>>>> It seems >>>>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33 >>>>> >>>>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: >> Java >>>> ignores system settings >>>>> Brought a dependency on 10.13. Was that intended ? Could we keep >> 10.12 >>>> compatibility ? >>>>> At least the doc of NSTextInputSourceIdentifier : >> https://developer.apple.com/documentation/appkit/nstextinputsourceiden >>>> tifier >>>>> mentions macOS 10.13+ . >>>>> >>>>> >>>>> >>>>> Build errors are : >>>>> ---------------------------- >>>>> >>>>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: >>>> error: unknown type name 'NSTextInputSourceIdentifier' >>>>> NSTextInputSourceIdentifier kbdLayout; >>>>> ^ >>>>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: >>>> error: assignment to readonly property >>>>> self.cglLayer = windowLayer; >>>>> ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~ >>>>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1 >>>> 9: error: assignment to readonly property >>>>> self.cglLayer = nil; >>>>> ~~~~~~~~~~~~~ ^ ~~~ >>>>> 3 errors generated. >>>>> >>>>> >>>>> ... >>>>> >> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45 >>>> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' >> (aka >>>> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion] >>>>> BOOL mouseIsOver = [[window contentView] mouseIsOver]; >>>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> 2 errors generated. >>>>> >>>>> >>>>> >>>>> Best regards, Matthias From erik.joelsson at oracle.com Wed Nov 27 13:44:58 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Nov 2019 05:44:58 -0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> <6f20a42b-4973-6a36-3f4c-0d834aee922d@oracle.com> Message-ID: <767a85a3-257a-dc80-18b6-0a200c632caa@oracle.com> On 2019-11-26 16:39, Weijun Wang wrote: > >> On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote: >> >> On 2019-11-25 16:42, Weijun Wang wrote: >>>> On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: >>>> >>>> Build change looks good. >>> Thanks. >>> >>> One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? >> No, we are not able to support different log levels to the main log file and console. What you can do is add $(LOG_INFO) or $(LOG_DEBUG) last on the command line. That macro resolves to "> /dev/null" when we don't want the output printed. How much output and how interesting is it to see? You can also wrap the whole command in a call to ExecuteWithLog to have it being logged to an individual file, which gets repeated at the end of the build in case it fails. >> >> I think you should be able to combine the two with something like this: >> >> $(call ExecuteWithLog, ...) $(LOG_DEBUG) >> >> That should print everything to the special log file as well as letting it pass to stdout when LOG=debug, but I haven't tested it. > The log shows on the console with LOG=debug but whatever LOG level I choose, the output is always collected in the log file. This is exactly what I am looking for. Note that it will not show up in build.log, but in a special log file just for this command, along with a .cmdline file for this command. The location of these files need to be provided to ExecuteWithLog in the first argument, as a basename for the files. In this case it would make sense to store them next to the touch file of the rule. /Erik > Thanks, > Max > >> /Erik >> >>> I copied everything from CLDR_GEN_DONE but that one does not log anything actually. >>> >>> I can remove all output too, not really important. >>> >>> Thanks, >>> Max >>> >>>> /Erik >>>> >>>> On 2019-11-22 18:59, Weijun Wang wrote: >>>>> Please review the change at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ >>>>> >>>>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. >>>>> >>>>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. >>>>> >>>>> Other smaller changes made to FieldGen.jsh: >>>>> >>>>> 1. Package name >>>>> 2. No more jshell, but now Java >>>>> 3. Input/output paths as args for main() >>>>> 4. White spaces, wrapping and indentation >>>>> >>>>> Thanks, >>>>> Max >>>>> From andy.herrick at oracle.com Wed Nov 27 14:07:19 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Nov 2019 09:07:19 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <5DDDD8F9.3060906@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> <5DDDD8F9.3060906@oracle.com> Message-ID: <5f88f4a4-4019-db9e-16b1-0efdd9ff0590@oracle.com> yes - The attempted incremental patch is not much use.? The source files were moved several times, and despite using "hg addremove -s 60", many of the files show as a remove and a new file. /Andy On 11/26/2019 9:01 PM, Philip Race wrote: > > I believe otherwise it is an accurate incremental webrev of the > jpackage changes since EA-5. > > It is also not very incremental. > * > *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java > > is definitely not "new" ... > > -phil. > > On 11/26/19, 2:17 PM, Andy Herrick wrote: >> yes,? this incremental webrev contains the JNLPConverter code, which >> it should not. >> >> I believe otherwise it is an accurate incremental webrev of the >> jpackage changes since EA-5. >> >> /Andy >> >> On 11/26/2019 4:53 PM, Phil Race wrote: >>> Andy, >>> >>> I am puzzled by what I see here >>> > The webrev at [3] shows the changes since EA-06 (Build >>> 13-jpackage+1-49 ) up to the current point. >>> >>> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>> >>> This includes the JNLPConverter which isn't what I expected to see and >>> (correctly) isn't in the cumulative webrev .... >>> >>> Since [3] seemed like the most obvious thing to do a review of the >>> recent >>> changes I'd like to be sure it has the correct content and I am not >>> sure it does ... >>> >>> -phil. >>> >>> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>>> This all looks good. >>>> >>>> +1 >>>> >>>> -- Kevin >>>> >>>> >>>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>>> (adding build-dev) >>>>> >>>>> Build changes look good. >>>>> >>>>> /Erik >>>>> >>>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>>> I posted new composite webrev [7], and git patch [8] after >>>>>> pushing fix for JDK-8234402 [6]. >>>>>> >>>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>>> >>>>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>>> >>>>>> /Andy >>>>>> >>>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>>> applied it, and verified that it is the same as what is in the >>>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs >>>>>>> fine for me. >>>>>>> >>>>>>> I ran jcheck and it found the following three files with >>>>>>> whitespace errors that will need to be fixed before you push: >>>>>>> >>>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>>> Trailing whitespace >>>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>>> Trailing whitespace >>>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>>>> whitespace >>>>>>> >>>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>>>> webrev, right? >>>>>>> >>>>>>> Pending the fix for JDK-8234402 and the needed white-space >>>>>>> fixes, this is a +1 from me (although I am not a jdk Project >>>>>>> Reviewer, so you will need at least one review from someone who >>>>>>> is). >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>>> >>>>>>> >>>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>>> Please review? changes for [1] which is the implementation bug >>>>>>>> for JEP-343. >>>>>>>> >>>>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>>>> the jpackage tool, currently in the JDK-8200758-branch branch >>>>>>>> of the open sandbox repository. >>>>>>>> >>>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>>> >>>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>>> >>>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>>> >>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>>> >>>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>>> >>>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>>> >>>>>>> >>>> >>> From matthias.baesken at sap.com Wed Nov 27 16:36:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 27 Nov 2019 16:36:38 +0000 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code Message-ID: Hello Martin, I checked building libjvm.so with -Os (instead of -O3) . I used gcc-7 on linux x86_64 . The size of libjvm.so dropped from 24M (normal night make with -O3) to 18M ( test make with -Os) . (adding the link-time gc might reduce the size by another ~ 10 % , but those 2 builds were without the ltgc ) Cannot say much so far about performance impact . Best regards, Matthias > > Hi Matthias and Erik, > > I also think this is an interesting option. > > I like the idea to generate smaller libraries. In addition to that, I could also > imagine building with -Os (size optimized) by default and only select -O3 for > performance critical files (e.g. C2's register allocation, some gc code, ...). > > If we want to go into such a direction for all linux platforms and want to use > this s390 only change as some kind of pipe cleaner, I think this change is fine > and can get pushed. > Otherwise, I think building s390 differently and not intending to do the same > for other linux platforms would be not so good. > > We should only make sure the exported symbols are set up properly to avoid > that this optimization throws out too much. > > My 50 Cents. > > Best regards, > Martin > From daniel.smith at oracle.com Wed Nov 27 17:04:21 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 27 Nov 2019 10:04:21 -0700 Subject: RFR: 8234835 Use UTF-8 charset in make support Java code Message-ID: Please review this patch to make explicit use of the UTF-8 charset in build tools' IO code. JDK-8065704 changed the platform default to US-ASCII, so the intended effect of this change is to address a regression and restore the typical earlier behavior. My particular interest is in fixuppandoc, but it seems like we might has well patch all of this code to avoid relying on the platform default. http://cr.openjdk.java.net/~dlsmith/8234835/ From claes.redestad at oracle.com Wed Nov 27 17:57:06 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 Nov 2019 18:57:06 +0100 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> Hi, we discussed doing the opposite for Mac OS X recently, where builds are currently set to -Os by default. -O3 helped various networking (micro)benchmarks by up to 20%. Rather than doing -Os by default and then cherry-pick things over to -O3 on a case-by-case basis, I'd suggest the opposite: keep -O3 as the default, start evaluating -Os on a case-by-case basis. This allows for an incremental approach where we identify things that are definitely not performance critical, e.g., never shows up in profiles, and switch those compilation units over to -Os. Check for harmful performance impact and expected footprint improvement; rinse; repeat. $.02 /Claes On 2019-11-27 17:36, Baesken, Matthias wrote: > Hello Martin, I checked building libjvm.so with -Os (instead of -O3) . > > I used gcc-7 on linux x86_64 . > The size of libjvm.so dropped from 24M (normal night make with -O3) to 18M ( test make with -Os) . > (adding the link-time gc might reduce the size by another ~ 10 % , but those 2 builds were without the ltgc ) > > Cannot say much so far about performance impact . > > Best regards, Matthias > > > >> >> Hi Matthias and Erik, >> >> I also think this is an interesting option. >> >> I like the idea to generate smaller libraries. In addition to that, I could also >> imagine building with -Os (size optimized) by default and only select -O3 for >> performance critical files (e.g. C2's register allocation, some gc code, ...). >> >> If we want to go into such a direction for all linux platforms and want to use >> this s390 only change as some kind of pipe cleaner, I think this change is fine >> and can get pushed. >> Otherwise, I think building s390 differently and not intending to do the same >> for other linux platforms would be not so good. >> >> We should only make sure the exported symbols are set up properly to avoid >> that this optimization throws out too much. >> >> My 50 Cents. >> >> Best regards, >> Martin >> > From jonathan.gibbons at oracle.com Wed Nov 27 17:53:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Nov 2019 09:53:55 -0800 Subject: RFR: 8234835 Use UTF-8 charset in make support Java code In-Reply-To: References: Message-ID: <3ca93b06-2c91-fc03-b4d5-99449cb90fb9@oracle.com> fixuppandoc is notable because it reads generated files .. which presumably contain non-ASCII UTF-8 characters. For the other files, it seems strange to force the use of a charset which is different from the charset of record for all our source files (i.e. US-ASCII).? I'm not saying that UTF-8 isn't a good choice, but it seems questionable to be inconsistent. --Jon On 11/27/19 9:04 AM, Dan Smith wrote: > Please review this patch to make explicit use of the UTF-8 charset in build tools' IO code. > > JDK-8065704 changed the platform default to US-ASCII, so the intended effect of this change is to address a regression and restore the typical earlier behavior. > > My particular interest is in fixuppandoc, but it seems like we might has well patch all of this code to avoid relying on the platform default. > > http://cr.openjdk.java.net/~dlsmith/8234835/ From martin.doerr at sap.com Wed Nov 27 18:03:59 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 Nov 2019 18:03:59 +0000 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> References: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> Message-ID: Hi Claes, that kind of surprises me. I'd expect files which rather benefit from -O3 to be far less than those which benefit from -Os. Most performance critical code lives inside the code cache and is not dependent on C++ compiler optimizations. I'd expect GC code, C2's register allocation and a few runtime files to be the most performance critical C++ code. So the list of files for -Os may become long. Yeah, I think we should use native profiling information to find out what's really going on. Your idea to change file by file and check for performance regression makes sense to me, though. Best regards, Martin > -----Original Message----- > From: Claes Redestad > Sent: Mittwoch, 27. November 2019 18:57 > To: Baesken, Matthias ; Doerr, Martin > ; Erik Joelsson ; 'build- > dev at openjdk.java.net' ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: building libjvm with -Os for space optimization - was : RE: RFR: > 8234525: enable link-time section-gc for linux s390x to remove unused code > > Hi, > > we discussed doing the opposite for Mac OS X recently, where builds are > currently set to -Os by default. -O3 helped various networking > (micro)benchmarks by up to 20%. > > Rather than doing -Os by default and then cherry-pick things over to -O3 > on a case-by-case basis, I'd suggest the opposite: keep -O3 as the > default, start evaluating -Os on a case-by-case basis. This allows for > an incremental approach where we identify things that are definitely not > performance critical, e.g., never shows up in profiles, and switch those > compilation units over to -Os. Check for harmful performance impact and > expected footprint improvement; rinse; repeat. > > $.02 > > /Claes > > > On 2019-11-27 17:36, Baesken, Matthias wrote: > > Hello Martin, I checked building libjvm.so with -Os (instead of -O3) . > > > > I used gcc-7 on linux x86_64 . > > The size of libjvm.so dropped from 24M (normal night make with -O3) > to 18M ( test make with -Os) . > > (adding the link-time gc might reduce the size by another ~ 10 % , but > those 2 builds were without the ltgc ) > > > > Cannot say much so far about performance impact . > > > > Best regards, Matthias > > > > > > > >> > >> Hi Matthias and Erik, > >> > >> I also think this is an interesting option. > >> > >> I like the idea to generate smaller libraries. In addition to that, I could also > >> imagine building with -Os (size optimized) by default and only select -O3 > for > >> performance critical files (e.g. C2's register allocation, some gc code, ...). > >> > >> If we want to go into such a direction for all linux platforms and want to > use > >> this s390 only change as some kind of pipe cleaner, I think this change is > fine > >> and can get pushed. > >> Otherwise, I think building s390 differently and not intending to do the > same > >> for other linux platforms would be not so good. > >> > >> We should only make sure the exported symbols are set up properly to > avoid > >> that this optimization throws out too much. > >> > >> My 50 Cents. > >> > >> Best regards, > >> Martin > >> > > From martinrb at google.com Wed Nov 27 18:18:34 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Nov 2019 10:18:34 -0800 Subject: RFR: 8234835 Use UTF-8 charset in make support Java code In-Reply-To: References: Message-ID: The ubiquitous use of UTF-8 is one of the few clear successes in the software world. In 2019, most software projects should declare that all their source files are encoded in UTF-8, not US-ASCII. On Wed, Nov 27, 2019 at 9:04 AM Dan Smith wrote: > Please review this patch to make explicit use of the UTF-8 charset in > build tools' IO code. > > JDK-8065704 changed the platform default to US-ASCII, so the intended > effect of this change is to address a regression and restore the typical > earlier behavior. > > My particular interest is in fixuppandoc, but it seems like we might has > well patch all of this code to avoid relying on the platform default. > > http://cr.openjdk.java.net/~dlsmith/8234835/ From jonathan.gibbons at oracle.com Wed Nov 27 19:36:45 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Nov 2019 11:36:45 -0800 Subject: RFR: 8234835 Use UTF-8 charset in make support Java code In-Reply-To: References: Message-ID: <41a2b70b-b1fa-d627-6763-c5b62b0ba2c8@oracle.com> Martin, Agreed, but this is not the email-thread to have that discussion on behalf of all OpenJDK. -- Jon On 11/27/2019 10:18 AM, Martin Buchholz wrote: > The ubiquitous use of UTF-8 is one of the few clear successes in the > software world. > In 2019, most software projects should declare that all their source files > are encoded in UTF-8, not US-ASCII. > > On Wed, Nov 27, 2019 at 9:04 AM Dan Smith wrote: > >> Please review this patch to make explicit use of the UTF-8 charset in >> build tools' IO code. >> >> JDK-8065704 changed the platform default to US-ASCII, so the intended >> effect of this change is to address a regression and restore the typical >> earlier behavior. >> >> My particular interest is in fixuppandoc, but it seems like we might has >> well patch all of this code to avoid relying on the platform default. >> >> http://cr.openjdk.java.net/~dlsmith/8234835/ From claes.redestad at oracle.com Wed Nov 27 22:35:15 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 Nov 2019 23:35:15 +0100 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> Message-ID: <84420dee-9889-b320-253b-f00551a2c9da@oracle.com> Hi Martin, On 2019-11-27 19:03, Doerr, Martin wrote: > Hi Claes, > > that kind of surprises me. I'd expect files which rather benefit from -O3 to be far less than those which benefit from -Os. > Most performance critical code lives inside the code cache and is not dependent on C++ compiler optimizations. > I'd expect GC code, C2's register allocation and a few runtime files to be the most performance critical C++ code. > So the list of files for -Os may become long. that might very well be the end result, and once/if we've gone down this path long enough to see that -O3 becomes the exception, we can re- examine the default. Changing the default and then trying to recuperate would be hard/impossible to do incrementally. > > Yeah, I think we should use native profiling information to find out what's really going on > > Your idea to change file by file and check for performance regression makes sense to me, though Hopefully we don't have to do one RFE per file.. :-) /Claes From weijun.wang at oracle.com Thu Nov 28 01:37:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 Nov 2019 09:37:19 +0800 Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes during build In-Reply-To: <767a85a3-257a-dc80-18b6-0a200c632caa@oracle.com> References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com> <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com> <99C4CFC6-CCAC-4275-BCEB-78D2AD245A0D@oracle.com> <6f20a42b-4973-6a36-3f4c-0d834aee922d@oracle.com> <767a85a3-257a-dc80-18b6-0a200c632caa@oracle.com> Message-ID: <0CE7D622-D894-4028-AB1D-18F343A7E39C@oracle.com> > On Nov 27, 2019, at 9:44 PM, Erik Joelsson wrote: > > On 2019-11-26 16:39, Weijun Wang wrote: >> >>> On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote: >>> >>> On 2019-11-25 16:42, Weijun Wang wrote: >>>>> On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote: >>>>> >>>>> Build change looks good. >>>> Thanks. >>>> >>>> One question: I see the output to stdout from FieldGen.java shown in build. Is it possible to hide it but still store the output in the log file? >>> No, we are not able to support different log levels to the main log file and console. What you can do is add $(LOG_INFO) or $(LOG_DEBUG) last on the command line. That macro resolves to "> /dev/null" when we don't want the output printed. How much output and how interesting is it to see? You can also wrap the whole command in a call to ExecuteWithLog to have it being logged to an individual file, which gets repeated at the end of the build in case it fails. >>> >>> I think you should be able to combine the two with something like this: >>> >>> $(call ExecuteWithLog, ...) $(LOG_DEBUG) >>> >>> That should print everything to the special log file as well as letting it pass to stdout when LOG=debug, but I haven't tested it. >> The log shows on the console with LOG=debug but whatever LOG level I choose, the output is always collected in the log file. This is exactly what I am looking for. > > Note that it will not show up in build.log, but in a special log file just for this command, Yes, that's what I meant. > along with a .cmdline file for this command. The location of these files need to be provided to ExecuteWithLog in the first argument, as a basename for the files. In this case it would make sense to store them next to the touch file of the rule. Yes, that's what I copied from CLDR_GEN_DONE, the argument, and the touch. It does not have "$(LOG_DEBUG)" at the end of the call but it has no output anyway. The special log file is empty. Thanks, Max > > /Erik > >> Thanks, >> Max >> >>> /Erik >>> >>>> I copied everything from CLDR_GEN_DONE but that one does not log anything actually. >>>> >>>> I can remove all output too, not really important. >>>> >>>> Thanks, >>>> Max >>>> >>>>> /Erik >>>>> >>>>> On 2019-11-22 18:59, Weijun Wang wrote: >>>>>> Please review the change at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8234697/webrev.00/ >>>>>> >>>>>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file. >>>>>> >>>>>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before. >>>>>> >>>>>> Other smaller changes made to FieldGen.jsh: >>>>>> >>>>>> 1. Package name >>>>>> 2. No more jshell, but now Java >>>>>> 3. Input/output paths as args for main() >>>>>> 4. White spaces, wrapping and indentation >>>>>> >>>>>> Thanks, >>>>>> Max From daniel.smith at oracle.com Thu Nov 28 03:23:33 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 27 Nov 2019 20:23:33 -0700 Subject: RFR: 8234835 Use UTF-8 charset in make support Java code In-Reply-To: References: Message-ID: <98186A35-8B61-4918-B98A-3B411227984F@oracle.com> > For the other files, it seems strange to force the use of a charset > which is different from the charset of record for all our source files > (i.e. US-ASCII). Can you clarify where this "charset of record" rule comes from? Is this written down somewhere, or more of an oral tradition? The non-ASCII characters I'm working with are, in fact, in the original Markdown sources. If it's really important to avoid those in all sources, I could (reluctantly) use a different strategy. If the consensus is that the build tools should standardize on US-ASCII, I guess there's a separate question about whether we're willing to rely on the implicit platform default (now uniformly US-ASCII via command-line args), or whether it's better to be explicit about it (s/UTF_8/US_ASCII/ in my changeset). From martin.doerr at sap.com Thu Nov 28 09:24:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 28 Nov 2019 09:24:18 +0000 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: <84420dee-9889-b320-253b-f00551a2c9da@oracle.com> References: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> <84420dee-9889-b320-253b-f00551a2c9da@oracle.com> Message-ID: Hi Claes, yeah, that makes sense. > Hopefully we don't have to do one RFE per file.. :-) ? I should have written set of files or directories or whatever. Thanks for your input. Best regards, Martin > -----Original Message----- > From: Claes Redestad > Sent: Mittwoch, 27. November 2019 23:35 > To: Doerr, Martin ; Baesken, Matthias > ; Erik Joelsson ; > 'build-dev at openjdk.java.net' ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: building libjvm with -Os for space optimization - was : RE: RFR: > 8234525: enable link-time section-gc for linux s390x to remove unused code > > Hi Martin, > > On 2019-11-27 19:03, Doerr, Martin wrote: > > Hi Claes, > > > > that kind of surprises me. I'd expect files which rather benefit from -O3 to > be far less than those which benefit from -Os. > > Most performance critical code lives inside the code cache and is not > dependent on C++ compiler optimizations. > > I'd expect GC code, C2's register allocation and a few runtime files to be the > most performance critical C++ code. > > So the list of files for -Os may become long. > > that might very well be the end result, and once/if we've gone down this > path long enough to see that -O3 becomes the exception, we can re- > examine the default. Changing the default and then trying to recuperate > would be hard/impossible to do incrementally. > > > > > Yeah, I think we should use native profiling information to find out what's > really going on > > > Your idea to change file by file and check for performance regression > makes sense to me, though > Hopefully we don't have to do one RFE per file.. :-) > > /Claes From Pengfei.Li at arm.com Fri Nov 29 03:56:50 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 29 Nov 2019 03:56:50 +0000 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 Message-ID: Hi, Please help review this small fix for 64-bit client build. Webrev: http://cr.openjdk.java.net/~pli/rfr/8234791/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8234791 Current 64-bit client VM build fails because errors occurred in dumping the CDS archive. In JDK 12, we enabled "Default CDS Archives"[1] which runs "java -Xshare:dump" after linking the JDK image. But for Client VM build on 64-bit platforms, the ergonomic flag UseCompressedOops is not set.[2] This leads to VM exits in checking the flags for dumping the shared archive.[3] This change removes the "#if defined" macro to make shared archive dump successful in 64-bit client build. By tracking the history of the macro, I found it is initially added as "#ifndef COMPILER1"[4] 10 years ago when C1 did not have a good support of compressed oops and modified to current shape[5] in the implementation of tiered compilation. It should be safe to be removed today. This patch also fixes another client build issue on AArch64. [1] http://openjdk.java.net/jeps/341 [2] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l1694 [3] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l3551 [4] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7 [5] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56 -- Thanks, Pengfei From adinn at redhat.com Fri Nov 29 09:19:12 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Nov 2019 09:19:12 +0000 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: Message-ID: <3e79b1e4-c548-dc3d-075f-e04e496d3863@redhat.com> Hi Pengfei, On 29/11/2019 03:56, Pengfei Li (Arm Technology China) wrote: > Please help review this small fix for 64-bit client build. > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8234791/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8234791 > > Current 64-bit client VM build fails because errors occurred in dumping > the CDS archive. In JDK 12, we enabled "Default CDS Archives"[1] which > runs "java -Xshare:dump" after linking the JDK image. But for Client VM > build on 64-bit platforms, the ergonomic flag UseCompressedOops is not > set.[2] This leads to VM exits in checking the flags for dumping the > shared archive.[3] > > This change removes the "#if defined" macro to make shared archive dump > successful in 64-bit client build. By tracking the history of the macro, > I found it is initially added as "#ifndef COMPILER1"[4] 10 years ago > when C1 did not have a good support of compressed oops and modified to > current shape[5] in the implementation of tiered compilation. It should > be safe to be removed today. > > This patch also fixes another client build issue on AArch64. > > [1] http://openjdk.java.net/jeps/341 > [2] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l1694 > [3] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l3551 > [4] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7 > [5] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56 Your explanation sounds correct and the change to arguments.cpp looks good. Can you explain why you have modified sharedRuntime_aarch64.cpp to include nativeInst_aarch64.hpp? I don't see any other change in the source file that would make this necessary. 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 Pengfei.Li at arm.com Fri Nov 29 10:01:37 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 29 Nov 2019 10:01:37 +0000 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: <3e79b1e4-c548-dc3d-075f-e04e496d3863@redhat.com> References: <3e79b1e4-c548-dc3d-075f-e04e496d3863@redhat.com> Message-ID: Hi Andrew Dinn, > Your explanation sounds correct and the change to arguments.cpp looks > good. > > Can you explain why you have modified sharedRuntime_aarch64.cpp to > include nativeInst_aarch64.hpp? I don't see any other change in the source > file that would make this necessary. Thanks for review. There is another build error below after I fixed arguments.cpp. For target hotspot_variant-client_libjvm_objs_sharedRuntime_aarch64.o: ....../src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp:2836:22: error: 'NativeInstruction' has not been declared __ add(r20, r20, NativeInstruction::instruction_size); We see that sharedRuntime_aarch64.cpp uses NativeInstruction but doesn't include nativeInst_aarch64.hpp. There is no error in Server VM build because the header file is included indirectly from some C2 file. But for Client VM build where C2 files are not in, this error occurs. -- Thanks, Pengfei From aph at redhat.com Fri Nov 29 10:11:33 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Nov 2019 10:11:33 +0000 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: <3e79b1e4-c548-dc3d-075f-e04e496d3863@redhat.com> Message-ID: <6af3f9d1-f1e3-7f03-6056-fd0c36af65b7@redhat.com> On 11/29/19 10:01 AM, Pengfei Li (Arm Technology China) wrote: > Thanks for review. There is another build error below after I fixed arguments.cpp. > > For target hotspot_variant-client_libjvm_objs_sharedRuntime_aarch64.o: > ....../src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp:2836:22: error: 'NativeInstruction' has not been declared > __ add(r20, r20, NativeInstruction::instruction_size); > > We see that sharedRuntime_aarch64.cpp uses NativeInstruction but doesn't include nativeInst_aarch64.hpp. > There is no error in Server VM build because the header file is included indirectly from some C2 file. > But for Client VM build where C2 files are not in, this error occurs. 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 adinn at redhat.com Fri Nov 29 10:20:40 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 Nov 2019 10:20:40 +0000 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: <3e79b1e4-c548-dc3d-075f-e04e496d3863@redhat.com> Message-ID: HiPengfei, On 29/11/2019 10:01, Pengfei Li (Arm Technology China) wrote: >> Can you explain why you have modified sharedRuntime_aarch64.cpp to >> include nativeInst_aarch64.hpp? I don't see any other change in the source >> file that would make this necessary. > > Thanks for review. There is another build error below after I fixed arguments.cpp. > > For target hotspot_variant-client_libjvm_objs_sharedRuntime_aarch64.o: > ....../src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp:2836:22: error: 'NativeInstruction' has not been declared > __ add(r20, r20, NativeInstruction::instruction_size); > > We see that sharedRuntime_aarch64.cpp uses NativeInstruction but doesn't include nativeInst_aarch64.hpp. > There is no error in Server VM build because the header file is included indirectly from some C2 file. > But for Client VM build where C2 files are not in, this error occurs. Ok, in that case the patch is good to push. 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 ioi.lam at oracle.com Sat Nov 30 01:02:29 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 29 Nov 2019 17:02:29 -0800 Subject: RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: Message-ID: <0b33fa95-ff15-b628-1891-f990f239e60f@oracle.com> Hi Pengfei, I have cc-ed hotspot-compiler-dev at openjdk.java.net. Please do not push the patch until someone from hotspot-compiler-dev has looked at it. Many people are away due to Thanksgiving in the US. Thanks - Ioi On 11/28/19 7:56 PM, Pengfei Li (Arm Technology China) wrote: > Hi, > > Please help review this small fix for 64-bit client build. > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8234791/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8234791 > > Current 64-bit client VM build fails because errors occurred in dumping > the CDS archive. In JDK 12, we enabled "Default CDS Archives"[1] which > runs "java -Xshare:dump" after linking the JDK image. But for Client VM > build on 64-bit platforms, the ergonomic flag UseCompressedOops is not > set.[2] This leads to VM exits in checking the flags for dumping the > shared archive.[3] > > This change removes the "#if defined" macro to make shared archive dump > successful in 64-bit client build. By tracking the history of the macro, > I found it is initially added as "#ifndef COMPILER1"[4] 10 years ago > when C1 did not have a good support of compressed oops and modified to > current shape[5] in the implementation of tiered compilation. It should > be safe to be removed today. > > This patch also fixes another client build issue on AArch64. > > [1] http://openjdk.java.net/jeps/341 > [2] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l1694 > [3] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l3551 > [4] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7 > [5] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56 > > -- > Thanks, > Pengfei > From ioi.lam at oracle.com Sat Nov 30 01:13:37 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 29 Nov 2019 17:13:37 -0800 Subject: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: <3bffe1cf-4567-0cf6-4bfb-ad79bd0b9596@oracle.com> Message-ID: On 11/27/19 10:03 AM, Doerr, Martin wrote: > Hi Claes, > > that kind of surprises me. I'd expect files which rather benefit from -O3 to be far less than those which benefit from -Os. > Most performance critical code lives inside the code cache and is not dependent on C++ compiler optimizations. > I'd expect GC code, C2's register allocation and a few runtime files to be the most performance critical C++ code. > So the list of files for -Os may become long. Class loading/verification/resolution are also sensitive to C++ speed. Thanks - Ioi > Yeah, I think we should use native profiling information to find out what's really going on. > > Your idea to change file by file and check for performance regression makes sense to me, though. > > Best regards, > Martin > > >> -----Original Message----- >> From: Claes Redestad >> Sent: Mittwoch, 27. November 2019 18:57 >> To: Baesken, Matthias ; Doerr, Martin >> ; Erik Joelsson ; 'build- >> dev at openjdk.java.net' ; 'hotspot- >> dev at openjdk.java.net' >> Subject: Re: building libjvm with -Os for space optimization - was : RE: RFR: >> 8234525: enable link-time section-gc for linux s390x to remove unused code >> >> Hi, >> >> we discussed doing the opposite for Mac OS X recently, where builds are >> currently set to -Os by default. -O3 helped various networking >> (micro)benchmarks by up to 20%. >> >> Rather than doing -Os by default and then cherry-pick things over to -O3 >> on a case-by-case basis, I'd suggest the opposite: keep -O3 as the >> default, start evaluating -Os on a case-by-case basis. This allows for >> an incremental approach where we identify things that are definitely not >> performance critical, e.g., never shows up in profiles, and switch those >> compilation units over to -Os. Check for harmful performance impact and >> expected footprint improvement; rinse; repeat. >> >> $.02 >> >> /Claes >> >> >> On 2019-11-27 17:36, Baesken, Matthias wrote: >>> Hello Martin, I checked building libjvm.so with -Os (instead of -O3) . >>> >>> I used gcc-7 on linux x86_64 . >>> The size of libjvm.so dropped from 24M (normal night make with -O3) >> to 18M ( test make with -Os) . >>> (adding the link-time gc might reduce the size by another ~ 10 % , but >> those 2 builds were without the ltgc ) >>> Cannot say much so far about performance impact . >>> >>> Best regards, Matthias >>> >>> >>> >>>> Hi Matthias and Erik, >>>> >>>> I also think this is an interesting option. >>>> >>>> I like the idea to generate smaller libraries. In addition to that, I could also >>>> imagine building with -Os (size optimized) by default and only select -O3 >> for >>>> performance critical files (e.g. C2's register allocation, some gc code, ...). >>>> >>>> If we want to go into such a direction for all linux platforms and want to >> use >>>> this s390 only change as some kind of pipe cleaner, I think this change is >> fine >>>> and can get pushed. >>>> Otherwise, I think building s390 differently and not intending to do the >> same >>>> for other linux platforms would be not so good. >>>> >>>> We should only make sure the exported symbols are set up properly to >> avoid >>>> that this optimization throws out too much. >>>> >>>> My 50 Cents. >>>> >>>> Best regards, >>>> Martin >>>>