From alexandr.miloslavskiy at gmail.com Tue Oct 1 10:27:14 2019 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Tue, 1 Oct 2019 12:27:14 +0200 Subject: How to native debug Java on macOS? In-Reply-To: <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> References: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com> <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com> <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com> <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com> <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> Message-ID: <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> Sorry about very late reply. Did quite a bit of experimenting, trying to get back that pesky 'EXC_BAD_ACCESS' problem. Long story short, I will go straight to the interesting stuff, answering your questions is no longer needed. When I use lldb to start my program like `lldb ~/Downloads/program` then 'os::_polling_page' exceptions are seen as continuable 'SIGBUS'. When I use lldb to attach to running process with `lldb -p` then 'os::_polling_page' exceptions are seen as non-continuable 'EXC_BAD_ACCESS'. At this moment, I lack the knowledge to explain this difference. To verify that you're dealing with same 'os::_polling_page' exceptions in both cases: 1) 'SIGBUS' scenario: thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGBUS 0x10647fb56: testl %eax, (%r10) (lldb) print/x $r10 0x00000001000fd008 (lldb) print _ZN2os13_polling_pageE 0x00000001000fd000 These two are obviously related. 2) 'EXC_BAD_ACCESS' scenario: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x105c4d008) (lldb) print _ZN2os13_polling_pageE 0x0000000105c4d000 Notice '0x105c4d008' vs '0x0000000105c4d000'. From leo.korinth at oracle.com Tue Oct 1 11:23:07 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 1 Oct 2019 13:23:07 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) Message-ID: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Hi, Please review these fixes to copyright headers (comma is added). This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, so that we do not have to do this in the future. Webrev: http://cr.openjdk.java.net/~lkorinth/8231671/00 Bug: https://bugs.openjdk.java.net/browse/JDK-8231671 Testing: None. Thanks, Leo From thomas.schatzl at oracle.com Tue Oct 1 11:28:23 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 1 Oct 2019 13:28:23 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: <0d234344-25f0-218c-6536-071696147c81@oracle.com> References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Message-ID: Hi, On 01.10.19 13:23, Leo Korinth wrote: > Hi, > > Please review these fixes to copyright headers (comma is added). > > This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, so > that we do not have to do this in the future. > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8231671/00 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8231671 > > Testing: > None. Can you run the scripts mentioned in https://bugs.openjdk.java.net/browse/JDK-8231660? Looks good. Thomas From david.holmes at oracle.com Tue Oct 1 11:35:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Oct 2019 21:35:41 +1000 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: <0d234344-25f0-218c-6536-071696147c81@oracle.com> References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Message-ID: Hi Leo, Looks good and trivial. I'm somewhat surprised these didn't get picked up in earlier copyright checks that were done. :( Thanks, David On 1/10/2019 9:23 pm, Leo Korinth wrote: > Hi, > > Please review these fixes to copyright headers (comma is added). > > This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, so > that we do not have to do this in the future. > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8231671/00 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8231671 > > Testing: > None. > > Thanks, > Leo From thomas.schatzl at oracle.com Tue Oct 1 12:46:07 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 1 Oct 2019 14:46:07 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Message-ID: <3a4bdde4-d70f-506f-8d20-f3964f89c8f4@oracle.com> hi, On 01.10.19 14:45, Leo Korinth wrote: > On 01/10/2019 13:28, Thomas Schatzl wrote: >> Hi, >> >> On 01.10.19 13:23, Leo Korinth wrote: >>> Hi, >>> >>> Please review these fixes to copyright headers (comma is added). >>> >>> This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, >>> so that we do not have to do this in the future. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lkorinth/8231671/00 >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8231671 >>> >>> Testing: >>> None. >> >> Can you run the scripts mentioned in >> https://bugs.openjdk.java.net/browse/JDK-8231660? > > Hi! > > The script is showing too many false positives, so I will not run the > script on all files. My changes does pass though, sorry for not > mentioning it. > > git log --name-only --pretty=oneline HEAD~..HEAD | tail -n+2 | xargs > bash make/scripts/lic_check.sh -gpl > > (all five files do pass) > > Is that enough? > ship it :) And I agree with David about triviality. Thomas From leo.korinth at oracle.com Tue Oct 1 12:45:19 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 1 Oct 2019 14:45:19 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Message-ID: On 01/10/2019 13:28, Thomas Schatzl wrote: > Hi, > > On 01.10.19 13:23, Leo Korinth wrote: >> Hi, >> >> Please review these fixes to copyright headers (comma is added). >> >> This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, >> so that we do not have to do this in the future. >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8231671/00 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8231671 >> >> Testing: >> None. > > Can you run the scripts mentioned in > https://bugs.openjdk.java.net/browse/JDK-8231660? Hi! The script is showing too many false positives, so I will not run the script on all files. My changes does pass though, sorry for not mentioning it. git log --name-only --pretty=oneline HEAD~..HEAD | tail -n+2 | xargs bash make/scripts/lic_check.sh -gpl (all five files do pass) Is that enough? Thanks, Leo > > Looks good. > > Thomas From leo.korinth at oracle.com Tue Oct 1 12:50:55 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 1 Oct 2019 14:50:55 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: <3a4bdde4-d70f-506f-8d20-f3964f89c8f4@oracle.com> References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> <3a4bdde4-d70f-506f-8d20-f3964f89c8f4@oracle.com> Message-ID: <486e38dc-7fc4-f552-df43-d95f8545b8a2@oracle.com> On 01/10/2019 14:46, Thomas Schatzl wrote: > hi, > > On 01.10.19 14:45, Leo Korinth wrote: >> On 01/10/2019 13:28, Thomas Schatzl wrote: >>> Hi, >>> >>> On 01.10.19 13:23, Leo Korinth wrote: >>>> Hi, >>>> >>>> Please review these fixes to copyright headers (comma is added). >>>> >>>> This is tiresome. I have asked Yoshiki Sato to file a fix for >>>> jcheck, so that we do not have to do this in the future. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~lkorinth/8231671/00 >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8231671 >>>> >>>> Testing: >>>> None. >>> >>> Can you run the scripts mentioned in >>> https://bugs.openjdk.java.net/browse/JDK-8231660? >> >> Hi! >> >> The script is showing too many false positives, so I will not run the >> script on all files. My changes does pass though, sorry for not >> mentioning it. >> >> git log --name-only --pretty=oneline HEAD~..HEAD | tail -n+2 | xargs >> bash make/scripts/lic_check.sh -gpl >> >> (all five files do pass) >> >> Is that enough? >> > > ? ship it :) And I agree with David about triviality. > > Thomas Thank you for your review! /Leo From leo.korinth at oracle.com Tue Oct 1 13:31:42 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 1 Oct 2019 15:31:42 +0200 Subject: RFR: 8231671: Fix copyright headers in hotspot (missing comma after year) In-Reply-To: References: <0d234344-25f0-218c-6536-071696147c81@oracle.com> Message-ID: On 01/10/2019 13:35, David Holmes wrote: > Hi Leo, > > Looks good and trivial. Thank you for your review! > > I'm somewhat surprised these didn't get picked up in earlier copyright > checks that were done. :( I believe the script does not really work as intended (without really looking at it). I /guess/ Yoshiki Sato is doing manual work. Someone who knows the real requirement should fix the script and make it work for every push. I asked Yoshiki Sato who usually creates these bug reports to fix jcheck so that we get rid of this. I also told him not to create multiple bug reports (I merged three to ease review pain). Thanks, Leo > > Thanks, > David > > On 1/10/2019 9:23 pm, Leo Korinth wrote: >> Hi, >> >> Please review these fixes to copyright headers (comma is added). >> >> This is tiresome. I have asked Yoshiki Sato to file a fix for jcheck, >> so that we do not have to do this in the future. >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8231671/00 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8231671 >> >> Testing: >> None. >> >> Thanks, >> Leo From bob.vandette at oracle.com Tue Oct 1 14:43:14 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 1 Oct 2019 10:43:14 -0400 Subject: RFR: 8230848: OSContainer: Refactor container detection code In-Reply-To: References: Message-ID: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> Severin, I?d prefer if you just added cgroupv2 support with these types of changes all at the same time. Having to look at two patches is just more work for nothing. In terms of your factoring approach, I don?t see why you need to move so much logic out of os_linux.cpp. The OSContainer interface should be used independent of which cgroup implementation is active. os_linux should use the existing OSContainer interface. OSContainer_linux should include the logic which selects cgroupv1 versus cgroupv2 and calls through a common cgroupSubsystem_linux class. This cgroupSubsystem_linux class should provide common functions that both v1 and v2 use. I?d then expect to see cgroupV1Subsystem_linux.?pp and cgroupV2Subsystem_linux.?pp files which extends cgroupSubsystem and contain version specific functions. Bob. > On Sep 19, 2019, at 10:20 AM, Severin Gehwolf wrote: > > Hi, > > Please review this code refactoring which will help getting a cgroups > v2 implementation for OSContainer implemented. The proposed changes are > mentioned in the bug. In essence, after this patch only methods > actually called in os_linux.cpp are exposed via OSContainer. Everything > else remains an implementation detail. After this refactoring it should > also be clearer what the actual bits implemented via cgroups v1 are in > hotspot. Functionally there should be no difference before and after > this patch. > > If you are curious where I'm going with this, have a look at JDK- > 8230305 which has a draft of an implementation of cgroups v2 building > on top of this patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230848 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ > > Testing: jdk-submit, tier1 tests on Linux x86_64, container tests > with docker and podman. > > Thoughts? > > Thanks, > Severin > From chris.plummer at oracle.com Tue Oct 1 17:04:24 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 1 Oct 2019 10:04:24 -0700 Subject: How to native debug Java on macOS? In-Reply-To: <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> References: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com> <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com> <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com> <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com> <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> Message-ID: <188065e5-f5bb-9592-badd-e58e1ad46dfb@oracle.com> Hi Alexander, That's very interesting and useful info. I was indeed always launching the app from a shell first, and then attaching from xcode. I'll have to try launching directly from lldb. BTW, it looks like in both cases the bad address is the polling page + 8, so I'm not too sure the point you are trying to make about that. thanks, Chris On 10/1/19 3:27 AM, Alexander Miloslavskiy wrote: > Sorry about very late reply. > > Did quite a bit of experimenting, trying to get back that pesky > 'EXC_BAD_ACCESS' problem. Long story short, I will go straight to the > interesting stuff, answering your questions is no longer needed. > > When I use lldb to start my program like `lldb ~/Downloads/program` > then 'os::_polling_page' exceptions are seen as continuable 'SIGBUS'. > > When I use lldb to attach to running process with `lldb -p` then > 'os::_polling_page' exceptions are seen as non-continuable > 'EXC_BAD_ACCESS'. > > At this moment, I lack the knowledge to explain this difference. > > To verify that you're dealing with same 'os::_polling_page' exceptions > in both cases: > 1) 'SIGBUS' scenario: > ?? thread #1, queue = 'com.apple.main-thread', stop reason = signal > SIGBUS > ???? 0x10647fb56: testl? %eax, (%r10) > ?? (lldb) print/x $r10 > ???? 0x00000001000fd008 > ?? (lldb) print _ZN2os13_polling_pageE > ???? 0x00000001000fd000 > ?? These two are obviously related. > 2) 'EXC_BAD_ACCESS' scenario: > ?? thread #1, queue = 'com.apple.main-thread', stop reason = > EXC_BAD_ACCESS (code=2, address=0x105c4d008) > ?? (lldb) print _ZN2os13_polling_pageE > ???? 0x0000000105c4d000 > ?? Notice '0x105c4d008' vs '0x0000000105c4d000'. From alexandr.miloslavskiy at gmail.com Tue Oct 1 17:06:08 2019 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Tue, 1 Oct 2019 19:06:08 +0200 Subject: How to native debug Java on macOS? In-Reply-To: <188065e5-f5bb-9592-badd-e58e1ad46dfb@oracle.com> References: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com> <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com> <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com> <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com> <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> <188065e5-f5bb-9592-badd-e58e1ad46dfb@oracle.com> Message-ID: On 01.10.2019 19:04, Chris Plummer wrote: > BTW, it looks like in both cases the bad address is the polling page + > 8, so I'm not too sure the point you are trying to make about that. "Page" is usually 4KB. From sgehwolf at redhat.com Tue Oct 1 17:54:43 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 19:54:43 +0200 Subject: RFR: 8230848: OSContainer: Refactor container detection code In-Reply-To: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> References: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> Message-ID: <039f28333ef106f846d73c86ffddac69bdb20af0.camel@redhat.com> Hi Bob, Thanks for looking at this! I appreciate that. On Tue, 2019-10-01 at 10:43 -0400, Bob Vandette wrote: > Severin, > > I?d prefer if you just added cgroupv2 support with these types of changes all at the same time. > Having to look at two patches is just more work for nothing. OK. I guess that's reviewer preference :) The reason why I did it that way is to keep the patch sizes smaller. Personally, I tend to find smaller, incremental patches easier to review than one gigantic patch. Do you want me to fold these three bugs/patches together and produce one big patch? no-op refactoring: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ added cgroups v2: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ add Metrics.java support for cgroups v2: > In terms of your factoring approach, I don?t see why you need to move so much logic out of os_linux.cpp. I do find the code easier to follow if the exposed interfaces of os_container are minimal and kept more broad. To some extent the osContainer interface is a leaky abstraction. Example: after the refactoring we'd generally have (in pseudo code): julong available_memory() { if (isContainerized()) { return container_available_memory(); } return system_available_memory(); } over having the osContainer impl in osLinux directly: julong available_memory() { if (isContainerized()) { mem_limit = container_mem_limit(); if (error) { trace_container(...) } mem_usage = container_memory_usage(); if (error) { trace_container(...) } if (mem_limit > 0 && mem_usage > 0) { return mem_limit > mem_usage ? mem_limit - mem_usage : 0; } } return system_available_memory(); } Perhaps that's just me. We should perhaps do a similar refactoring for physical memory... > The OSContainer interface should be used independent of which cgroup implementation is active. Yes, agreed. I guess the disagreement is in the granularity of the interface functions. > os_linux should use the existing OSContainer interface. OK. If the OSContainer interface is set in stone I will change it back. My concern was that it exposes too many functions for no good reason not needed by os_linux (the only consumer). Most functions are used by print_container_info() anyway, which could be kept more general. Perhaps I'm missing something? > OSContainer_linux should include the logic which selects cgroupv1 versus cgroupv2 and > calls through a common cgroupSubsystem_linux class. This cgroupSubsystem_linux class > should provide common functions that both v1 and v2 use. Yes. If you look at the cgroups v2 patch, that's what is being proposed. CgroupSubsystemFactory::create() is being called from OsContainer_linux. The factory does the selection and returns the abstract cgroupSubsystem class (either v1 or v2): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ > I?d then expect to see cgroupV1Subsystem_linux.?pp and cgroupV2Subsystem_linux.?pp files which > extends cgroupSubsystem and contain version specific functions. Sure, I'd be happy to move things into version specific files if that's desired. Currently, I've kept them in cgroupSubsystem_linux.{c,h}pp. It shouldn't be hard to separeate them out. It makes sense to do it actually. Thanks again for you input! Cheers, Severin > Bob. > > > > On Sep 19, 2019, at 10:20 AM, Severin Gehwolf wrote: > > > > Hi, > > > > Please review this code refactoring which will help getting a cgroups > > v2 implementation for OSContainer implemented. The proposed changes are > > mentioned in the bug. In essence, after this patch only methods > > actually called in os_linux.cpp are exposed via OSContainer. Everything > > else remains an implementation detail. After this refactoring it should > > also be clearer what the actual bits implemented via cgroups v1 are in > > hotspot. Functionally there should be no difference before and after > > this patch. > > > > If you are curious where I'm going with this, have a look at JDK- > > 8230305 which has a draft of an implementation of cgroups v2 building > > on top of this patch. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230848 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ > > > > Testing: jdk-submit, tier1 tests on Linux x86_64, container tests > > with docker and podman. > > > > Thoughts? > > > > Thanks, > > Severin > > From bob.vandette at oracle.com Tue Oct 1 18:36:39 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 1 Oct 2019 14:36:39 -0400 Subject: RFR: 8230848: OSContainer: Refactor container detection code In-Reply-To: <039f28333ef106f846d73c86ffddac69bdb20af0.camel@redhat.com> References: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> <039f28333ef106f846d73c86ffddac69bdb20af0.camel@redhat.com> Message-ID: > On Oct 1, 2019, at 1:54 PM, Severin Gehwolf wrote: > > Hi Bob, > > Thanks for looking at this! I appreciate that. > > On Tue, 2019-10-01 at 10:43 -0400, Bob Vandette wrote: >> Severin, >> >> I?d prefer if you just added cgroupv2 support with these types of changes all at the same time. >> Having to look at two patches is just more work for nothing. > > OK. I guess that's reviewer preference :) The reason why I did it that > way is to keep the patch sizes smaller. Personally, I tend to find > smaller, incremental patches easier to review than one gigantic patch. > Do you want me to fold these three bugs/patches together and produce > one big patch? Others may disagree but I?d prefer one big patch since they are very tightly related. > > no-op refactoring: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ > > added cgroups v2: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ > > add Metrics.java support for cgroups v2: > > >> In terms of your factoring approach, I don?t see why you need to move so much logic out of os_linux.cpp. > > I do find the code easier to follow if the exposed interfaces of > os_container are minimal and kept more broad. To some extent the > osContainer interface is a leaky abstraction. Example: after the > refactoring we'd generally have (in pseudo code): > > julong available_memory() { > if (isContainerized()) { > return container_available_memory(); > } > return system_available_memory(); > } > > over having the osContainer impl in osLinux directly: > > julong available_memory() { > if (isContainerized()) { > mem_limit = container_mem_limit(); > if (error) { > trace_container(...) > } > mem_usage = container_memory_usage(); > if (error) { > trace_container(...) > } > if (mem_limit > 0 && mem_usage > 0) { > return mem_limit > mem_usage ? mem_limit - mem_usage : 0; > } > } > return system_available_memory(); > } > > Perhaps that's just me. We should perhaps do a similar refactoring for > physical memory? I didn?t want to drag a lot of the logic from os_linux.cpp into the container implementation and wanted to try to keep a separation of pure os configuration and container configuration. I also envisioned cases were there might be non cgroup containers that we?d need to support. There?s already Kata containers but that one looks just like a pure os execution. > >> The OSContainer interface should be used independent of which cgroup implementation is active. > > Yes, agreed. I guess the disagreement is in the granularity of the > interface functions. > >> os_linux should use the existing OSContainer interface. > > OK. If the OSContainer interface is set in stone I will change it back. > > My concern was that it exposes too many functions for no good reason > not needed by os_linux (the only consumer). Most functions are used by > print_container_info() anyway, which could be kept more general. > Perhaps I'm missing something? The original intent was to provide a container metrics API that would be used by the VM startup, JFR events and Management MBeans to provide more visibility into a container. I?m still hopeful that we?ll eventually get the last two. I?ve had discussions with the serviceability team and there?s an interested party in doing the JFR events. > >> OSContainer_linux should include the logic which selects cgroupv1 versus cgroupv2 and >> calls through a common cgroupSubsystem_linux class. This cgroupSubsystem_linux class >> should provide common functions that both v1 and v2 use. > > Yes. If you look at the cgroups v2 patch, that's what is being > proposed. CgroupSubsystemFactory::create() is being called from > OsContainer_linux. The factory does the selection and returns the > abstract cgroupSubsystem class (either v1 or v2): > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ > >> I?d then expect to see cgroupV1Subsystem_linux.?pp and cgroupV2Subsystem_linux.?pp files which >> extends cgroupSubsystem and contain version specific functions. > > Sure, I'd be happy to move things into version specific files if that's > desired. Currently, I've kept them in cgroupSubsystem_linux.{c,h}pp. It > shouldn't be hard to separeate them out. It makes sense to do it > actually. > > Thanks again for you input! No, problem and thanks for doing this work. BTW: Can you tell me if there?s a .dockerenv file in the fedora/podman?s container / directory or is it a .podmanenv file? I?m wondering if I can use the existence of these files as the triigger that we?re containerized. This is for another bug. Bob. > > Cheers, > Severin > >> Bob. >> >> >>> On Sep 19, 2019, at 10:20 AM, Severin Gehwolf wrote: >>> >>> Hi, >>> >>> Please review this code refactoring which will help getting a cgroups >>> v2 implementation for OSContainer implemented. The proposed changes are >>> mentioned in the bug. In essence, after this patch only methods >>> actually called in os_linux.cpp are exposed via OSContainer. Everything >>> else remains an implementation detail. After this refactoring it should >>> also be clearer what the actual bits implemented via cgroups v1 are in >>> hotspot. Functionally there should be no difference before and after >>> this patch. >>> >>> If you are curious where I'm going with this, have a look at JDK- >>> 8230305 which has a draft of an implementation of cgroups v2 building >>> on top of this patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230848 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ >>> >>> Testing: jdk-submit, tier1 tests on Linux x86_64, container tests >>> with docker and podman. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >>> > From sgehwolf at redhat.com Tue Oct 1 19:00:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 21:00:32 +0200 Subject: RFR: 8230848: OSContainer: Refactor container detection code In-Reply-To: References: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> <039f28333ef106f846d73c86ffddac69bdb20af0.camel@redhat.com> Message-ID: On Tue, 2019-10-01 at 14:36 -0400, Bob Vandette wrote: > BTW: Can you tell me if there?s a .dockerenv file in the > fedora/podman?s container / directory or is it a .podmanenv file? > I?m wondering if I can use the existence of these files as the > triigger that we?re containerized. This is for another bug. According to [1] it's '/run/.containerenv' for podman. $ sudo docker run --rm -ti fedora:30 /bin/bash -c "ls /.dockerenv" /.dockerenv $ podman run -ti --rm fedora:31 /bin/bash -c "ls /run/.containerenv" /run/.containerenv $ sudo docker run --rm -ti fedora:30 /bin/bash -c "cat /.dockerenv" $ podman run -ti --rm fedora:31 /bin/bash -c "cat /run/.containerenv" $ Thanks, Severin [1] https://github.com/containers/libpod/issues/648 From sgehwolf at redhat.com Tue Oct 1 19:03:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 21:03:12 +0200 Subject: RFR: 8230848: OSContainer: Refactor container detection code In-Reply-To: References: <075CF828-911E-4664-BEC0-F4F52DDC9896@oracle.com> <039f28333ef106f846d73c86ffddac69bdb20af0.camel@redhat.com> Message-ID: <04a0e7f953a44b9dd71b43af0e0deacd2a5b4aa3.camel@redhat.com> On Tue, 2019-10-01 at 14:36 -0400, Bob Vandette wrote: > > On Oct 1, 2019, at 1:54 PM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > Thanks for looking at this! I appreciate that. > > > > On Tue, 2019-10-01 at 10:43 -0400, Bob Vandette wrote: > > > Severin, > > > > > > I?d prefer if you just added cgroupv2 support with these types of changes all at the same time. > > > Having to look at two patches is just more work for nothing. > > > > OK. I guess that's reviewer preference :) The reason why I did it that > > way is to keep the patch sizes smaller. Personally, I tend to find > > smaller, incremental patches easier to review than one gigantic patch. > > Do you want me to fold these three bugs/patches together and produce > > one big patch? > > Others may disagree but I?d prefer one big patch since they are very tightly related. > > > no-op refactoring: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/03/webrev/ > > > > added cgroups v2: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ > > > > add Metrics.java support for cgroups v2: > > > > > > > In terms of your factoring approach, I don?t see why you need to move so much logic out of os_linux.cpp. > > > > I do find the code easier to follow if the exposed interfaces of > > os_container are minimal and kept more broad. To some extent the > > osContainer interface is a leaky abstraction. Example: after the > > refactoring we'd generally have (in pseudo code): > > > > julong available_memory() { > > if (isContainerized()) { > > return container_available_memory(); > > } > > return system_available_memory(); > > } > > > > over having the osContainer impl in osLinux directly: > > > > julong available_memory() { > > if (isContainerized()) { > > mem_limit = container_mem_limit(); > > if (error) { > > trace_container(...) > > } > > mem_usage = container_memory_usage(); > > if (error) { > > trace_container(...) > > } > > if (mem_limit > 0 && mem_usage > 0) { > > return mem_limit > mem_usage ? mem_limit - mem_usage : 0; > > } > > } > > return system_available_memory(); > > } > > > > Perhaps that's just me. We should perhaps do a similar refactoring for > > physical memory? > > I didn?t want to drag a lot of the logic from os_linux.cpp into the container implementation > and wanted to try to keep a separation of pure os configuration and container configuration. > I also envisioned cases were there might be non cgroup containers that we?d need to support. > There?s already Kata containers but that one looks just like a pure os execution. > > > > The OSContainer interface should be used independent of which cgroup implementation is active. > > > > Yes, agreed. I guess the disagreement is in the granularity of the > > interface functions. > > > > > os_linux should use the existing OSContainer interface. > > > > OK. If the OSContainer interface is set in stone I will change it back. > > > > My concern was that it exposes too many functions for no good reason > > not needed by os_linux (the only consumer). Most functions are used by > > print_container_info() anyway, which could be kept more general. > > Perhaps I'm missing something? > > The original intent was to provide a container metrics API that would be used by the VM startup, > JFR events and Management MBeans to provide more visibility into a container. > I?m still hopeful that we?ll eventually get the last two. I?ve had discussions with the serviceability > team and there?s an interested party in doing the JFR events. > > > > OSContainer_linux should include the logic which selects cgroupv1 versus cgroupv2 and > > > calls through a common cgroupSubsystem_linux class. This cgroupSubsystem_linux class > > > should provide common functions that both v1 and v2 use. > > > > Yes. If you look at the cgroups v2 patch, that's what is being > > proposed. CgroupSubsystemFactory::create() is being called from > > OsContainer_linux. The factory does the selection and returns the > > abstract cgroupSubsystem class (either v1 or v2): > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/05/webrev/ > > > > > I?d then expect to see cgroupV1Subsystem_linux.?pp and cgroupV2Subsystem_linux.?pp files which > > > extends cgroupSubsystem and contain version specific functions. > > > > Sure, I'd be happy to move things into version specific files if that's > > desired. Currently, I've kept them in cgroupSubsystem_linux.{c,h}pp. It > > shouldn't be hard to separeate them out. It makes sense to do it > > actually. > > > > Thanks again for you input! > > No, problem and thanks for doing this work. OK. I'll see to get this into a shape you're happy with and come back to you. Thanks, Severin From vitalyd at gmail.com Tue Oct 1 22:30:59 2019 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 1 Oct 2019 18:30:59 -0400 Subject: How to native debug Java on macOS? In-Reply-To: References: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com> <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com> <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com> <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com> <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> <188065e5-f5bb-9592-badd-e58e1ad46dfb@oracle.com> Message-ID: On Tue, Oct 1, 2019 at 1:08 PM Alexander Miloslavskiy < alexandr.miloslavskiy at gmail.com> wrote: > On 01.10.2019 19:04, Chris Plummer wrote: > > BTW, it looks like in both cases the bad address is the polling page + > > 8, so I'm not too sure the point you are trying to make about that. > > "Page" is usually 4KB. > Looks like the base poll page addresses are 4k aligned if you take the 8 out. The 8 is a value hotspot uses to differentiate an armed vs disarmed page but only when threadlocal handshakes are used, AFAIK. See https://github.com/openjdk/jdk11u/blob/29c30e723c284f97019f1644e8ed72195fc24683/src/hotspot/share/runtime/safepointMechanism.cpp#L42 Have you tried disabling threadlocal handshakes? -- Sent from my phone From david.holmes at oracle.com Wed Oct 2 03:17:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Oct 2019 13:17:20 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com> <6015a0d9-3ec9-ffb1-50da-b5723041c79c@oracle.com> Message-ID: <450656fc-a856-22d0-3e1d-9642e5e188b8@oracle.com> Hi Matthias, On 30/09/2019 8:14 pm, Baesken, Matthias wrote: >> >> I'm unclear about the details of the test. Does this: >> 77 Stream si = NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses); >> not also return the loopback address that was already tested? Could it >> return interfaces that we really don't want to be trying to test? > > Hi David, > yes we are sending to all Inetadresses of all adapters ( at least the ones that are not in status DOWN, I noticed that the Java/net JDK classes omit those on Linux ). > I think it is not a bad idea to send to all to get the "right" one but maybe the original test owners might comment on this . I don't see any point sending explicitly to the loopback address and then have that repeated when you loop through all the interfaces. I don't know enough about the psuedo/virtual adapters to know whether including them makes sense. > 88 } catch(IOException ioe) { > 89 } > >> Why are we silently swallowing exceptions here? > > I agree , we should at least give some output for this case of send failures . > >> The test is sometimes failing on Windows (2 out of 5 runs): > > Thanks for testing ! > Bad to hear about the failures , is it failing too without my patch ? It might be a separate issue you observe . It's hard to run the test on the exact same machines. The point is that this "more stable" test is still failing. > Events.hasEvents(events); fails in your example below looking at the stacktrace - there seems to be something very wrong with the JFR event generating and/or capturing on the machine you test . Then we need the JFR folk to chime in and see why we're not getting the expected events. Thanks, David > Best regards, Matthias > > >> >> Hi Matthias, >> >> The test is sometimes failing on Windows (2 out of 5 runs): >> >> java.lang.RuntimeException: No events: expected false, was true >> at jdk.test.lib.Asserts.fail(Asserts.java:594) >> at jdk.test.lib.Asserts.assertFalse(Asserts.java:461) >> at jdk.test.lib.jfr.Events.hasEvents(Events.java:158) >> at >> jdk.jfr.event.runtime.TestNetworkUtilizationEvent.main(TestNetworkUtiliza >> tionEvent.java:98) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet >> hodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega >> tingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp >> er.java:127) >> at java.base/java.lang.Thread.run(Thread.java:830) >> >> The main output shows we are duplicating the write to the loopback >> address and I think we're trying to write to too many interfaces: >> >> ----------System.out:(12/660)---------- >> [0.796s][trace][jfr,event] Reporting network utilization >> [0.811s][trace][jfr,event] Reporting network utilization >> InetAddress.getLoopbackAddress :localhost/127.0.0.1 host address:127.0.0.1 >> Sending to InetAddress:/127.0.0.1 >> Sending to InetAddress:/0:0:0:0:0:0:0:1 >> Sending to InetAddress:/ >> Sending to InetAddress:/%eth4 >> Sending to InetAddress:/ >> Sending to InetAddress:/%net5 >> [6.943s][trace][jfr,event] Reporting network utilization >> [6.950s][trace][jfr,event] Reporting network utilization >> [6.957s][trace][jfr,event] Reporting network utilization >> >> On a passing test I see: >> >> [6.947s][trace][jfr,event] Reporting network utilization >> [6.947s][trace][jfr,event] found data for NetworkInterface Oracle VirtIO >> Ethernet Adapter (read_rate 19, write_rate 10) >> [6.952s][trace][jfr,event] Reporting network utilization >> [6.960s][trace][jfr,event] Reporting network utilization >> jdk.NetworkUtilization { >> startTime = 00:36:46.904 >> networkInterface = "Oracle VirtIO Ethernet Adapter" >> readRate = 152 bps >> writeRate = 80 bps >> } >> >> but I have no idea to which of the 6 INetAddress entries this corresponds. >> >> David >> >> On 29/09/2019 10:17 am, David Holmes wrote: >>> Hi Matthias, >>> >>> On 27/09/2019 8:56 pm, Baesken, Matthias wrote: >>>> Hi David /? Mikhailo ,? I? adjusted the test a bit more , and also >>>> added?? (+enabled) UL-based?? jfr,event? tracing? in >>>> src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp >>>> ?? to better see? the recorded event information . >>>> >>>> The current revision >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.3/ >>>> >>>> sends?? DatagramPackets?? to???? all???? InetAddresses???? of??? all >>>> network interfaces? of the machine? . >>>> I observed? that on our "problematic" machine? where the test? fails >>>> we still need a little? delay?? to see the?? read / write?? counters >>>> (fetched by os_perf and then used in the JFR) >>>> ??? increase on the machine ( that?s why I wait a bit before every >>>> send operation). >>>> >>>> Could you? please? check?? 8229370.3??? also in your infrastructure >>>> where you noticed?? sporadic failures?? in >>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java?? and tell me >>>> ? about the results ? >>> >>> I've submitted a test run to our system. >>> >>> I'm unclear about the details of the test. Does this: >>> >>> ?77???????? Stream si = >>> >> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr >> esses); >>> >>> >>> not also return the loopback address that was already tested? Could it >>> return interfaces that we really don't want to be trying to test? >>> >>> ?88???????????? } catch(IOException ioe) { >>> ?89???????????? } >>> >>> Why are we silently swallowing exceptions here? >>> >>> Thanks, >>> David >>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> Subject: Re: RFR [XS]: 8229370: make >>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>> >>>>> Hi Matthias, >>>>> >>>>> On 24/09/2019 12:23 am, Baesken, Matthias wrote: >>>>>> Hi David /? Mikhailo , I was busy with other tasks? but today? got >>>>>> back to >>>>> 8229370 . >>>>>> >>>>>> I noticed that in the meantime,?? the test was excluded? with >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8230115 >>>>>> >>>>>> "Problemlist JFR TestNetworkUtilization test" >>>>>> >>>>>> >>>>>> Do you think we still should? rely? on the OS counters , and expect >>>>>> to get? 2+ >>>>> network interfaces,? or? keep? the test excluded (or just relax? the >>>>> check and >>>>> check for 1+? network interfaces on Linux)? ? >>>>> >>>>> Exclusion is just a temporary measure to clean up the testing results, >>>>> so this still needs to be fixed. I have nothing further to add from my >>>>> comments in the bug: >>>>> >>>>> ? > So it should be as simple as changing 10.0.0.0:12345 into something >>>>> ? > guaranteed to work? >>>>> ? > >>>>> ? > I think this needs to be looked at by the JFR folk and net-dev >>>>> folk to >>>>> ? > come up with a valid testing scenario. >>>>> >>>>> It's not the number of interfaces that is the issue, it is generating >>>>> traffic on the real interface. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On 29/08/2019 12:24 am, Baesken, Matthias wrote: >>>>>>>> Hi David ,?? I could? add some? optional? UL logging? to see >>>>>>>> what happens. >>>>>>> >>>>>>> I just want to see more visibility at the test level to ensure it is >>>>>>> finding the interfaces and addresses I would expect it to find. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Maybe the? OS counters?? that are fetched by?? os_perf??? are not >>>>>>>> that >>>>>>> reliable on some? kernels . >>>>>>>> >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> >>>>>> From matthias.baesken at sap.com Wed Oct 2 09:06:23 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 Oct 2019 09:06:23 +0000 Subject: RFR: 8231751: on aix handle Power 9 in os::get_summary_cpu_info Message-ID: Hello, please review this small change . It adds Power 9 handling to os::get_summary_cpu_info on AIX . Additionally some older macro definitions (like PV_6 ) are removed because they are present in sys/systemcfg.h on recent AIX versions ( 6.1 + ) . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231751 http://cr.openjdk.java.net/~mbaesken/webrevs/8231751.0/ Thanks, Matthias From alexandr.miloslavskiy at gmail.com Wed Oct 2 12:11:43 2019 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Wed, 2 Oct 2019 14:11:43 +0200 Subject: How to native debug Java on macOS? In-Reply-To: References: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com> <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com> <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com> <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com> <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com> <1486aedb-f590-b4d4-efeb-9bdf884f65f8@gmail.com> <188065e5-f5bb-9592-badd-e58e1ad46dfb@oracle.com> Message-ID: <598a07ab-5c83-2340-38cf-ce347ac34b9a@gmail.com> On 02.10.2019 0:30, Vitaly Davidovich wrote: > Have you tried disabling threadlocal handshakes? When struggling with lldb back then, I studied JDK code and concluded that these exceptions can't be avoided with options. From martin.doerr at sap.com Wed Oct 2 12:40:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 2 Oct 2019 12:40:51 +0000 Subject: RFR: 8231751: on aix handle Power 9 in os::get_summary_cpu_info In-Reply-To: References: Message-ID: Hi Matthias, looks good. Thanks, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Mittwoch, 2. Oktober 2019 11:06 > To: 'hotspot-dev at openjdk.java.net' ; > 'ppc-aix-port-dev at openjdk.java.net' > Subject: RFR: 8231751: on aix handle Power 9 in os::get_summary_cpu_info > > Hello, please review this small change . > > It adds Power 9 handling to os::get_summary_cpu_info on AIX . > Additionally some older macro definitions (like PV_6 ) are removed > because they are present > in sys/systemcfg.h on recent AIX versions ( 6.1 + ) . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231751 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231751.0/ > > > Thanks, Matthias From matthias.baesken at sap.com Wed Oct 2 12:40:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 Oct 2019 12:40:38 +0000 Subject: RFR : 8231753: use more Posix functionality in aix os::print_os_info Message-ID: Hello, please review the following small (mostly AIX related) change . It replaces the AIX coding in function void os::print_os_info(outputStream* st) { ... } for uname and load average info output by os::Posix functionality. Additionally it slightly changes os::Posix::print_load_average function to handle the return value of os::loadavg ( indicating failure ) . Bug / webrev : https://bugs.openjdk.java.net/browse/JDK-8231753 http://cr.openjdk.java.net/~mbaesken/webrevs/8231753.0/ Thanks, Matthias From david.holmes at oracle.com Wed Oct 2 13:07:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Oct 2019 23:07:39 +1000 Subject: RFR : 8231753: use more Posix functionality in aix os::print_os_info In-Reply-To: References: Message-ID: Hi Matthias, On 2/10/2019 10:40 pm, Baesken, Matthias wrote: > Hello, please review the following small (mostly AIX related) change . > > It replaces the AIX coding in function > void os::print_os_info(outputStream* st) { ... } > > > for uname and load average info output by os::Posix functionality. > Additionally it slightly changes os::Posix::print_load_average function to handle the return value of os::loadavg > ( indicating failure ) . Might I make a slight suggestion here: + st->print("Failed to obtain load average"); as this is not an error message but still forms part of the report i.e. it will print: load average:Failed to obtain load average that a simpler + st->print(" Unavailable"); would suffice to give: load average: Unavailable Otherwise changes appear fine. Thanks, David > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231753 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231753.0/ > > > Thanks, Matthias > From zgu at redhat.com Fri Oct 4 19:22:46 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 4 Oct 2019 15:22:46 -0400 Subject: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com> References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com> Message-ID: <6a1385ba-ab76-c6e6-df7c-ad6f0f6baa1e@redhat.com> Ping! May I get a second review? Thanks, -Zhengyu On 9/18/19 10:46 AM, Roman Kennke wrote: > Hi Zhengyu, > > It looks good to me! > > Thanks, > Roman > > >> Please review this patch that supports JNI critical functions in >> object pinning capable GCs on x86_32 platforms. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ >> >> Test: >> ?? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on >> Linux x86_64. >> ?? hotspot_gc, hotspot_runtime and hotspot_compiler >> ?? Submit tests in progress. >> >> Thanks, >> >> -Zhengyu From christoph.langer at sap.com Mon Oct 7 15:07:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Oct 2019 15:07:29 +0000 Subject: RFR: 8231751: on aix handle Power 9 in os::get_summary_cpu_info In-Reply-To: References: Message-ID: Looks good, Matthias. > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Mittwoch, 2. Oktober 2019 11:06 > To: 'hotspot-dev at openjdk.java.net' ; > 'ppc-aix-port-dev at openjdk.java.net' > Subject: RFR: 8231751: on aix handle Power 9 in os::get_summary_cpu_info > > Hello, please review this small change . > > It adds Power 9 handling to os::get_summary_cpu_info on AIX . > Additionally some older macro definitions (like PV_6 ) are removed > because they are present > in sys/systemcfg.h on recent AIX versions ( 6.1 + ) . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231751 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231751.0/ > > > Thanks, Matthias From christoph.langer at sap.com Mon Oct 7 15:11:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Oct 2019 15:11:49 +0000 Subject: RFR : 8231753: use more Posix functionality in aix os::print_os_info In-Reply-To: References: Message-ID: +1, also for David's suggestion. /Christoph > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of David Holmes > Sent: Mittwoch, 2. Oktober 2019 15:08 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'ppc-aix-port- > dev at openjdk.java.net' > Subject: Re: RFR : 8231753: use more Posix functionality in aix > os::print_os_info > > Hi Matthias, > > On 2/10/2019 10:40 pm, Baesken, Matthias wrote: > > Hello, please review the following small (mostly AIX related) change . > > > > It replaces the AIX coding in function > > void os::print_os_info(outputStream* st) { ... } > > > > > > for uname and load average info output by os::Posix functionality. > > Additionally it slightly changes os::Posix::print_load_average function to > handle the return value of os::loadavg > > ( indicating failure ) . > > Might I make a slight suggestion here: > > + st->print("Failed to obtain load average"); > > as this is not an error message but still forms part of the report i.e. > it will print: > > load average:Failed to obtain load average > > that a simpler > > + st->print(" Unavailable"); > > would suffice to give: > > load average: Unavailable > > Otherwise changes appear fine. > > Thanks, > David > > > Bug / webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8231753 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231753.0/ > > > > > > Thanks, Matthias > > From erik.osterlund at oracle.com Mon Oct 7 20:57:27 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 7 Oct 2019 22:57:27 +0200 Subject: RFR (S) 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe modification of inline cache In-Reply-To: References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com> <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com> <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com> <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com> <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com> <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com> <41FDE810-C699-41C2-B4B9-F35E15818028@oracle.com> Message-ID: Hi Coleen, Looks good. /Erik > On 27 Sep 2019, at 20:07, coleen.phillimore at oracle.com wrote: > > > So I should have done this in the first place. I consolidated the assert code and retested with Oracle platforms, aarch64 and zero. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.03/webrev > > And the volatiles are gone. > > Thanks, > Coleen > >> On 9/27/19 12:32 PM, Erik Osterlund wrote: >> Hi Coleen, >> >>> On 27 Sep 2019, at 15:46, coleen.phillimore at oracle.com wrote: >>> >>> >>> >>>> On 9/27/19 9:20 AM, erik.osterlund at oracle.com wrote: >>>> For any race to be observed, wouldn't we need to have concurrent writes not protected by the CompiledICLocker? If that indeed happens, then that seems like a bug, right? Or maybe I'm missing something. >>> I can't actually answer that because I didn't observe the races. Was this always protected by the CompiledICLocker? >> Yes. >> >>> I can remove the volatiles if they are protected by the CompiledICLocker. >> That would be great. >> >> Thanks, >> /Erik >> >>> Coleen >>> >>>> /Erik >>>> >>>>> On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>>> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> I don't understand this. It makes the frame-local variable volatile. But surely the frame local variable is accessed only by the current thread. And the whole thing is protected by the CompiledICLocker. Would you mind explaining what we are worried about here? >>>>> The worry is that old_method would be fetched multiple times from data() in the assert. Another thread could be updating data(), if I'm not mistaken. Making destination volatile might not be necessary, but it was like that in s390, which experienced the race. >>>>> >>>>> Coleen >>>>> >>>>>> Thanks, >>>>>> /Erik >>>>>> >>>>>>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> For the record, I added volatiles after discussions with Goetz: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev >>>>>>> >>>>>>> Which builds on s390 and ppc, and verified on Oracle platforms as well. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Thanks Erik! >>>>>>>> Coleen >>>>>>>> >>>>>>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted >>>>>>>>>> >>>>>>>>>> This is the comment in the bug that describes this race and this fix: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 >>>>>>>>>> >>>>>>>>>> The rest of the bug and sightings are actually caused by https://bugs.openjdk.java.net/browse/JDK-8226690, >>>>>>>>>> and this one might have been caused by it also, but the race that Erik describes is possible as well. >>>>>>>>>> >>>>>>>>>> The s390 code had an exception for callee->is_compiled_lambda_form() which should probably apply to all the platforms, so the code is the same on all the platforms with this change. >>>>>>>>>> >>>>>>>>>> Tested with tier1-6. >>>>>>>>>> >>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen > From matthias.baesken at sap.com Tue Oct 8 07:43:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 8 Oct 2019 07:43:43 +0000 Subject: RFR : 8231753: use more Posix functionality in aix os::print_os_info In-Reply-To: References: Message-ID: Hi Christoph and David, thanks for the reviews . I'll change the message following David's suggestion before pushing . Best regards, Matthias > +1, also for David's suggestion. > > /Christoph > > > -----Original Message----- > > From: ppc-aix-port-dev > On > > Behalf Of David Holmes > > Sent: Mittwoch, 2. Oktober 2019 15:08 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; 'ppc-aix-port- > > dev at openjdk.java.net' > > Subject: Re: RFR : 8231753: use more Posix functionality in aix > > os::print_os_info > > > > Hi Matthias, > > > > On 2/10/2019 10:40 pm, Baesken, Matthias wrote: > > > Hello, please review the following small (mostly AIX related) change . > > > > > > It replaces the AIX coding in function > > > void os::print_os_info(outputStream* st) { ... } > > > > > > > > > for uname and load average info output by os::Posix functionality. > > > Additionally it slightly changes os::Posix::print_load_average function to > > handle the return value of os::loadavg > > > ( indicating failure ) . > > > > Might I make a slight suggestion here: > > > > + st->print("Failed to obtain load average"); > > > > as this is not an error message but still forms part of the report i.e. > > it will print: > > > > load average:Failed to obtain load average > > > > that a simpler > > > > + st->print(" Unavailable"); > > > > would suffice to give: > > > > load average: Unavailable > > > > Otherwise changes appear fine. > > > > Thanks, > > David > > > > > Bug / webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8231753 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231753.0/ > > > > > > > > > Thanks, Matthias > > > From matthias.baesken at sap.com Tue Oct 8 11:16:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 8 Oct 2019 11:16:45 +0000 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures Message-ID: Hello, please review the following test related change . The test containers/docker/TestJcmdWithSideCar.java has been reactivated after https://bugs.openjdk.java.net/browse/JDK-8228960 and we see now sporadic failures. We needed to increase/adjust the timeouts and also check the Xmx setting going into the java calls in the docker containers (we might inherit when from the test java opts). Also a bit more output has been added to the tests to better understand potential issues . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8230957 http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ Thanks, Matthias From coleen.phillimore at oracle.com Tue Oct 8 13:00:23 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 8 Oct 2019 09:00:23 -0400 Subject: RFR (S) 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe modification of inline cache In-Reply-To: References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com> <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com> <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com> <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com> <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com> <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com> <41FDE810-C699-41C2-B4B9-F35E15818028@oracle.com> Message-ID: <3f0da9d2-70da-5aab-bb2e-665e8bf69286@oracle.com> Thanks Erik.? I agree with you about removing volatile. Coleen On 10/7/19 4:57 PM, Erik Osterlund wrote: > Hi Coleen, > > Looks good. > > /Erik > >> On 27 Sep 2019, at 20:07, coleen.phillimore at oracle.com wrote: >> >> >> So I should have done this in the first place. I consolidated the assert code and retested with Oracle platforms, aarch64 and zero. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.03/webrev >> >> And the volatiles are gone. >> >> Thanks, >> Coleen >> >>> On 9/27/19 12:32 PM, Erik Osterlund wrote: >>> Hi Coleen, >>> >>>> On 27 Sep 2019, at 15:46, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> >>>>> On 9/27/19 9:20 AM, erik.osterlund at oracle.com wrote: >>>>> For any race to be observed, wouldn't we need to have concurrent writes not protected by the CompiledICLocker? If that indeed happens, then that seems like a bug, right? Or maybe I'm missing something. >>>> I can't actually answer that because I didn't observe the races. Was this always protected by the CompiledICLocker? >>> Yes. >>> >>>> I can remove the volatiles if they are protected by the CompiledICLocker. >>> That would be great. >>> >>> Thanks, >>> /Erik >>> >>>> Coleen >>>> >>>>> /Erik >>>>> >>>>>> On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>>> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> I don't understand this. It makes the frame-local variable volatile. But surely the frame local variable is accessed only by the current thread. And the whole thing is protected by the CompiledICLocker. Would you mind explaining what we are worried about here? >>>>>> The worry is that old_method would be fetched multiple times from data() in the assert. Another thread could be updating data(), if I'm not mistaken. Making destination volatile might not be necessary, but it was like that in s390, which experienced the race. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> Thanks, >>>>>>> /Erik >>>>>>> >>>>>>>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> For the record, I added volatiles after discussions with Goetz: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev >>>>>>>> >>>>>>>> Which builds on s390 and ppc, and verified on Oracle platforms as well. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>> Thanks Erik! >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted >>>>>>>>>>> >>>>>>>>>>> This is the comment in the bug that describes this race and this fix: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 >>>>>>>>>>> >>>>>>>>>>> The rest of the bug and sightings are actually caused by https://bugs.openjdk.java.net/browse/JDK-8226690, >>>>>>>>>>> and this one might have been caused by it also, but the race that Erik describes is possible as well. >>>>>>>>>>> >>>>>>>>>>> The s390 code had an exception for callee->is_compiled_lambda_form() which should probably apply to all the platforms, so the code is the same on all the platforms with this change. >>>>>>>>>>> >>>>>>>>>>> Tested with tier1-6. >>>>>>>>>>> >>>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen From bob.vandette at oracle.com Tue Oct 8 13:22:35 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 8 Oct 2019 09:22:35 -0400 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: I don?t think it?s necessary to state the obvious here: 59 private static final long TIME_TO_WAIT_FOR_MAIN_METHOD_START = 50 * 1000; // milliseconds; increase 5 to 50 Where does this -999 come from? Is this documented anywhere? If so please define a constant. Would this work with podman? 237 int pev = -999; Could you give this a more descriptive name (retryCount maybe)? 238 int rt = 3; Bob. > On Oct 8, 2019, at 7:16 AM, Baesken, Matthias wrote: > > Hello, please review the following test related change . > > The test containers/docker/TestJcmdWithSideCar.java has been reactivated after > > https://bugs.openjdk.java.net/browse/JDK-8228960 > > and we see now sporadic failures. > > We needed to increase/adjust the timeouts and also check the Xmx setting going into the java calls in the docker containers (we might inherit when from the test java opts). > Also a bit more output has been added to the tests to better understand potential issues . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8230957 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ > > > Thanks, Matthias From matthias.baesken at sap.com Wed Oct 9 07:37:12 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Oct 2019 07:37:12 +0000 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: Hi Bob I changed the comment and renamed the variable to retryCount . -999 is just an initialization and has no special meaning . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ Best regards, Matthias > > I don?t think it?s necessary to state the obvious here: > > 59 private static final long TIME_TO_WAIT_FOR_MAIN_METHOD_START = > 50 * 1000; // milliseconds; increase 5 to 50 > > Where does this -999 come from? Is this documented anywhere? If so > please define a constant. Would this > work with podman? > > 237 int pev = -999; > > Could you give this a more descriptive name (retryCount maybe)? > > 238 int rt = 3; > > > Bob. > > > > On Oct 8, 2019, at 7:16 AM, Baesken, Matthias > wrote: > > > > Hello, please review the following test related change . > > > > The test containers/docker/TestJcmdWithSideCar.java has been > reactivated after > > > > https://bugs.openjdk.java.net/browse/JDK-8228960 > > > > and we see now sporadic failures. > > > > We needed to increase/adjust the timeouts and also check the Xmx setting > going into the java calls in the docker containers (we might inherit when from > the test java opts). > > Also a bit more output has been added to the tests to better understand > potential issues . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8230957 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ > > > > > > Thanks, Matthias From christoph.langer at sap.com Wed Oct 9 10:03:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 9 Oct 2019 10:03:56 +0000 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: Hi Matthias, looks good to me, too, overall and as it is active in our test system it proves to stabilize things. But, I agree to Bob in that you should rather define some constant like private static int EXIT_VALUE_INITIAL = -999; and use it to initialize and check pev. Thanks Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 9. Oktober 2019 09:37 > To: Bob Vandette > Cc: hotspot-dev at openjdk.java.net; Langer, Christoph > ; MIKHAILO_SELEDTSOV > > Subject: RE: RFR: 8230957: [TESTBUG] > containers/docker/TestJcmdWithSideCar.java sporadic failures > > Hi Bob I changed the comment and renamed the variable to retryCount . > -999 is just an initialization and has no special meaning . > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ > > Best regards, Matthias > > > > > > I don?t think it?s necessary to state the obvious here: > > > > 59 private static final long TIME_TO_WAIT_FOR_MAIN_METHOD_START > = > > 50 * 1000; // milliseconds; increase 5 to 50 > > > > Where does this -999 come from? Is this documented anywhere? If so > > please define a constant. Would this > > work with podman? > > > > 237 int pev = -999; > > > > Could you give this a more descriptive name (retryCount maybe)? > > > > 238 int rt = 3; > > > > > > Bob. > > > > > > > On Oct 8, 2019, at 7:16 AM, Baesken, Matthias > > wrote: > > > > > > Hello, please review the following test related change . > > > > > > The test containers/docker/TestJcmdWithSideCar.java has been > > reactivated after > > > > > > https://bugs.openjdk.java.net/browse/JDK-8228960 > > > > > > and we see now sporadic failures. > > > > > > We needed to increase/adjust the timeouts and also check the Xmx > setting > > going into the java calls in the docker containers (we might inherit when > from > > the test java opts). > > > Also a bit more output has been added to the tests to better understand > > potential issues . > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8230957 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ > > > > > > > > > Thanks, Matthias From matthias.baesken at sap.com Wed Oct 9 12:19:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Oct 2019 12:19:57 +0000 Subject: RFR [XS]: 8232052: use string literal for format string when handling PauseAtStartupFile Message-ID: Hello, please review the following change . Currently only on Linux (os_linux.cpp) the format string is a string literal and not a variable when handling the PauseAtStartupFile flag. This was done on Linux with https://bugs.openjdk.java.net/browse/JDK-8042894 when handling gcc warnings / warning related pragmas; however on the other platforms it is recommended to do the same. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8232052 http://cr.openjdk.java.net/~mbaesken/webrevs/8232052.0/ Thanks, Matthias From christoph.langer at sap.com Wed Oct 9 12:33:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 9 Oct 2019 12:33:57 +0000 Subject: RFR [XS]: 8232052: use string literal for format string when handling PauseAtStartupFile In-Reply-To: References: Message-ID: Hi Matthias, this seems fine and trivial. +1 Cheers Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Mittwoch, 9. Oktober 2019 14:20 > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR [XS]: 8232052: use string literal for format string when handling > PauseAtStartupFile > > Hello, please review the following change . > > Currently only on Linux (os_linux.cpp) the format string is a string literal and > not a variable when handling the PauseAtStartupFile flag. > This was done on Linux with > https://bugs.openjdk.java.net/browse/JDK-8042894 > when handling gcc warnings / warning related pragmas; however on the > other platforms it is recommended to do the same. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8232052 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232052.0/ > > > Thanks, Matthias From lois.foltan at oracle.com Wed Oct 9 21:18:50 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 9 Oct 2019 17:18:50 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently Message-ID: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> Please review this enhancement to consistently use the JVM_SIGNATURE_* constants for type signature processing.? This change is a precursor to JDK-8230199: consolidate signature parsing in Hotspot sources. open webrev at:http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.0/webrev/ bug link: https://bugs.openjdk.java.net/browse/JDK-8231844 contributed-by: Lois Foltan, John Rose Testing: hs-tier1-3, jdk-tier1-2 (all platforms).? hs-tier4-6 (linux only) Thanks, Lois From david.holmes at oracle.com Thu Oct 10 00:14:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2019 10:14:44 +1000 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> Message-ID: <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> Hi Lois, On 10/10/2019 7:18 am, Lois Foltan wrote: > Please review this enhancement to consistently use the JVM_SIGNATURE_* > constants for type signature processing.? This change is a precursor to > JDK-8230199: consolidate signature parsing in Hotspot sources. > > open webrev > at:http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.0/webrev/ > > bug link: https://bugs.openjdk.java.net/browse/JDK-8231844 > contributed-by: Lois Foltan, John Rose In general the change is good - special characters should be referred to by symbolic names to give more semantic context where practical. However I do have a few comments. It seems redundant and somewhat counter to the fix to change a character in the code to a symbolic constant but then have a comment still use the original character. Sometimes this seems acceptable as it helps clarity e.g. // Ignore wrapping L and ; ! if (name[0] == JVM_SIGNATURE_CLASS) { but in particular I found the comments here unnecessary: src/hotspot/share/utilities/globalDefinitions.cpp // Map BasicType to signature character ! char type2char_tab[T_CONFLICT+1] = { ! 0, 0, 0, 0, ! JVM_SIGNATURE_BOOLEAN, JVM_SIGNATURE_CHAR, // 4: 'Z', 'C' ! JVM_SIGNATURE_FLOAT, JVM_SIGNATURE_DOUBLE, // 'F', 'D' ! JVM_SIGNATURE_BYTE, JVM_SIGNATURE_SHORT, // 8: 'B', 'S' ! JVM_SIGNATURE_INT, JVM_SIGNATURE_LONG, // 'I', 'J' ! JVM_SIGNATURE_CLASS, JVM_SIGNATURE_ARRAY, // 12: 'L', '[' ! JVM_SIGNATURE_VOID, 0, // 'V' ! 0, 0, 0, 0 ! }; other cases could go either way. --- src/java.base/share/native/include/classfile_constants.h.template + JVM_SIGNATURE_ENDPACKAGE = '/', + JVM_SIGNATURE_ENDPACKAGE_DOT = '.', These constants bothered me both because of their very long names and because the names aren't completely accurate. They both indicate separators between identifiers: one for internal form, and one for external form. The / doesn't "end a package" and . can be part of a nested type name, unrelated to packages. As these characters do not have a unique semantic usage that is easily expressed, perhaps referring to them as just: JVM_SIGNATURE_SLASH JVM_SIGNATURE_DOT would suffice? --- src/hotspot/share/c1/c1_InstructionPrinter.cpp Should type2name really handle all cases and assert if an invalid type, and return "???" (or perhaps "") in product mode? --- src/hotspot/share/utilities/globalDefinitions.hpp I do not like this new method: +inline BasicType primitive_or_object(BasicType t) { + assert(is_java_type(t), "%d", (int)t); + return (is_reference_type(t) ? T_OBJECT : t); +} I found it's use in the code was far less clear than the original code. I like to explicitly see where arrays and objects are being treated the same (or differently). Thanks, David ----- > Testing: hs-tier1-3, jdk-tier1-2 (all platforms).? hs-tier4-6 (linux only) > > Thanks, > Lois From matthias.baesken at sap.com Thu Oct 10 06:45:59 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 10 Oct 2019 06:45:59 +0000 Subject: RFR [XS]: 8232052: use string literal for format string when handling PauseAtStartupFile In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review . Will push it as XS tomorrow in case of no objections . Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 9. Oktober 2019 14:34 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR [XS]: 8232052: use string literal for format string when > handling PauseAtStartupFile > > Hi Matthias, > > this seems fine and trivial. +1 > > Cheers > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Mittwoch, 9. Oktober 2019 14:20 > > To: 'hotspot-dev at openjdk.java.net' > > Subject: RFR [XS]: 8232052: use string literal for format string when handling > > PauseAtStartupFile > > > > Hello, please review the following change . > > > > Currently only on Linux (os_linux.cpp) the format string is a string literal and > > not a variable when handling the PauseAtStartupFile flag. > > This was done on Linux with > > https://bugs.openjdk.java.net/browse/JDK-8042894 > > when handling gcc warnings / warning related pragmas; however on the > > other platforms it is recommended to do the same. > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8232052 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232052.0/ > > > > > > Thanks, Matthias From thomas.stuefe at gmail.com Thu Oct 10 06:52:44 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Oct 2019 08:52:44 +0200 Subject: RFR [XS]: 8232052: use string literal for format string when handling PauseAtStartupFile In-Reply-To: References: Message-ID: LGTM ..Thomas On Thu, Oct 10, 2019 at 8:46 AM Baesken, Matthias wrote: > Hi Christoph, thanks for the review . > > Will push it as XS tomorrow in case of no objections . > > Best regards, Matthias > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Mittwoch, 9. Oktober 2019 14:34 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: RE: RFR [XS]: 8232052: use string literal for format string when > > handling PauseAtStartupFile > > > > Hi Matthias, > > > > this seems fine and trivial. +1 > > > > Cheers > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Mittwoch, 9. Oktober 2019 14:20 > > > To: 'hotspot-dev at openjdk.java.net' > > > Subject: RFR [XS]: 8232052: use string literal for format string when > handling > > > PauseAtStartupFile > > > > > > Hello, please review the following change . > > > > > > Currently only on Linux (os_linux.cpp) the format string is a string > literal and > > > not a variable when handling the PauseAtStartupFile flag. > > > This was done on Linux with > > > https://bugs.openjdk.java.net/browse/JDK-8042894 > > > when handling gcc warnings / warning related pragmas; however on the > > > other platforms it is recommended to do the same. > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8232052 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232052.0/ > > > > > > > > > Thanks, Matthias > From matthias.baesken at sap.com Thu Oct 10 07:39:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 10 Oct 2019 07:39:22 +0000 Subject: RFR [XS] : 8232060: add some initializations using sigemptyset in os_aix.cpp Message-ID: Hello, please review the following small patch . Currently a couple of initializations with sigemptyset are missing in os_aix.cpp, that are done in os_linux . Usually the missing sigemptyset calls should not be a problem, however in special cases (e.g. very seldom failing pthread_* calls later in the coding) they might lead to uninitialized sigset_t structs used . Bug/wevrev : https://bugs.openjdk.java.net/browse/JDK-8232060 http://cr.openjdk.java.net/~mbaesken/webrevs/8232060.0/ Thanks, Matthias From matthias.baesken at sap.com Thu Oct 10 07:45:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 10 Oct 2019 07:45:32 +0000 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: Hi Bob, may I add you as a reviewer too ? Are you fine with the current revision http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ ? Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 9. Oktober 2019 12:04 > To: Baesken, Matthias ; Bob Vandette > > Cc: hotspot-dev at openjdk.java.net; MIKHAILO_SELEDTSOV > > Subject: RE: RFR: 8230957: [TESTBUG] > containers/docker/TestJcmdWithSideCar.java sporadic failures > > Hi Matthias, > > looks good to me, too, overall and as it is active in our test system it proves to > stabilize things. > > But, I agree to Bob in that you should rather define some constant like > > private static int EXIT_VALUE_INITIAL = -999; > > and use it to initialize and check pev. > > Thanks > Christoph > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Mittwoch, 9. Oktober 2019 09:37 > > To: Bob Vandette > > Cc: hotspot-dev at openjdk.java.net; Langer, Christoph > > ; MIKHAILO_SELEDTSOV > > > > Subject: RE: RFR: 8230957: [TESTBUG] > > containers/docker/TestJcmdWithSideCar.java sporadic failures > > > > Hi Bob I changed the comment and renamed the variable to retryCount . > > -999 is just an initialization and has no special meaning . > > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ > > > > Best regards, Matthias > > > > > > > > > > I don?t think it?s necessary to state the obvious here: > > > > > > 59 private static final long > TIME_TO_WAIT_FOR_MAIN_METHOD_START > > = > > > 50 * 1000; // milliseconds; increase 5 to 50 > > > > > > Where does this -999 come from? Is this documented anywhere? If so > > > please define a constant. Would this > > > work with podman? > > > > > > 237 int pev = -999; > > > > > > Could you give this a more descriptive name (retryCount maybe)? > > > > > > 238 int rt = 3; > > > > > > > > > Bob. > > > > > > > > > > On Oct 8, 2019, at 7:16 AM, Baesken, Matthias > > > wrote: > > > > > > > > Hello, please review the following test related change . > > > > > > > > The test containers/docker/TestJcmdWithSideCar.java has been > > > reactivated after > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8228960 > > > > > > > > and we see now sporadic failures. > > > > > > > > We needed to increase/adjust the timeouts and also check the Xmx > > setting > > > going into the java calls in the docker containers (we might inherit when > > from > > > the test java opts). > > > > Also a bit more output has been added to the tests to better > understand > > > potential issues . > > > > > > > > > > > > Bug/webrev : > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8230957 > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ > > > > > > > > > > > > Thanks, Matthias From thomas.stuefe at gmail.com Thu Oct 10 10:21:25 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Oct 2019 12:21:25 +0200 Subject: RFR [XS] : 8232060: add some initializations using sigemptyset in os_aix.cpp In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. +1. ..Thomas On Thu, Oct 10, 2019 at 9:42 AM Baesken, Matthias wrote: > Hello, please review the following small patch . > > Currently a couple of initializations with sigemptyset are missing in > os_aix.cpp, that are done in os_linux . > Usually the missing sigemptyset calls should not be a problem, however in > special cases (e.g. very seldom failing pthread_* calls later in the > coding) they > might lead to uninitialized sigset_t structs used . > > > Bug/wevrev : > > https://bugs.openjdk.java.net/browse/JDK-8232060 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232060.0/ > > > Thanks, Matthias > From rkennke at redhat.com Thu Oct 10 11:22:27 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 10 Oct 2019 13:22:27 +0200 Subject: Possible bug in nmethod::flush_dependencies() Message-ID: We're encountering a bug with Shenandoah: https://bugs.openjdk.java.net/browse/JDK-8231999 That looks to me like an upstream bug in nmethod::flush_dependencies(). The assert that happens there is caused by call_site being NULL in flush_dependencies(). If you look at nmethod::flush_dependencies() (nmethod.cpp around lines 1533-1542) you'll see that it makes a DepStream from the nmethod. It then fetches argument_oop(0) from it. If you look at dependencies.cpp lines 978 DepStream::argument_oop() it will call recorded_oop_at() which (when using _code, which is the case here) will call nmethod::oop_at(). Which has if (index == 0) return NULL. In other words, the way the code is written, call_site is basically guaranteed to be NULL. Yet, java_lang_invoke_CallSite::context_no_keepalive() expects a non-NULL call_site argument. Maybe I am missing something? Can anybody make out how this is supposed to work? Thanks, Roman From bob.vandette at oracle.com Thu Oct 10 13:00:45 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 10 Oct 2019 09:00:45 -0400 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: I don?t feel too strongly about this but ? Can you change the name of ?pev? to exitValue? Can you maybe just use -1 as the initial value? You can add me as a reviewer. Bob. > On Oct 10, 2019, at 3:45 AM, Baesken, Matthias wrote: > > Hi Bob, may I add you as a reviewer too ? > Are you fine with the current revision > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ > > ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Mittwoch, 9. Oktober 2019 12:04 >> To: Baesken, Matthias ; Bob Vandette >> >> Cc: hotspot-dev at openjdk.java.net; MIKHAILO_SELEDTSOV >> >> Subject: RE: RFR: 8230957: [TESTBUG] >> containers/docker/TestJcmdWithSideCar.java sporadic failures >> >> Hi Matthias, >> >> looks good to me, too, overall and as it is active in our test system it proves to >> stabilize things. >> >> But, I agree to Bob in that you should rather define some constant like >> >> private static int EXIT_VALUE_INITIAL = -999; >> >> and use it to initialize and check pev. >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Mittwoch, 9. Oktober 2019 09:37 >>> To: Bob Vandette >>> Cc: hotspot-dev at openjdk.java.net; Langer, Christoph >>> ; MIKHAILO_SELEDTSOV >>> >>> Subject: RE: RFR: 8230957: [TESTBUG] >>> containers/docker/TestJcmdWithSideCar.java sporadic failures >>> >>> Hi Bob I changed the comment and renamed the variable to retryCount . >>> -999 is just an initialization and has no special meaning . >>> >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ >>> >>> Best regards, Matthias >>> >>> >>>> >>>> I don?t think it?s necessary to state the obvious here: >>>> >>>> 59 private static final long >> TIME_TO_WAIT_FOR_MAIN_METHOD_START >>> = >>>> 50 * 1000; // milliseconds; increase 5 to 50 >>>> >>>> Where does this -999 come from? Is this documented anywhere? If so >>>> please define a constant. Would this >>>> work with podman? >>>> >>>> 237 int pev = -999; >>>> >>>> Could you give this a more descriptive name (retryCount maybe)? >>>> >>>> 238 int rt = 3; >>>> >>>> >>>> Bob. >>>> >>>> >>>>> On Oct 8, 2019, at 7:16 AM, Baesken, Matthias >>>> wrote: >>>>> >>>>> Hello, please review the following test related change . >>>>> >>>>> The test containers/docker/TestJcmdWithSideCar.java has been >>>> reactivated after >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8228960 >>>>> >>>>> and we see now sporadic failures. >>>>> >>>>> We needed to increase/adjust the timeouts and also check the Xmx >>> setting >>>> going into the java calls in the docker containers (we might inherit when >>> from >>>> the test java opts). >>>>> Also a bit more output has been added to the tests to better >> understand >>>> potential issues . >>>>> >>>>> >>>>> Bug/webrev : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8230957 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ >>>>> >>>>> >>>>> Thanks, Matthias > From mikhailo.seledtsov at oracle.com Thu Oct 10 17:05:42 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 10 Oct 2019 10:05:42 -0700 Subject: RFR: 8230957: [TESTBUG] containers/docker/TestJcmdWithSideCar.java sporadic failures In-Reply-To: References: Message-ID: Looks good to me, Misha On 10/10/19 12:45 AM, Baesken, Matthias wrote: > Hi Bob, may I add you as a reviewer too ? > Are you fine with the current revision > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ > > ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Mittwoch, 9. Oktober 2019 12:04 >> To: Baesken, Matthias ; Bob Vandette >> >> Cc: hotspot-dev at openjdk.java.net; MIKHAILO_SELEDTSOV >> >> Subject: RE: RFR: 8230957: [TESTBUG] >> containers/docker/TestJcmdWithSideCar.java sporadic failures >> >> Hi Matthias, >> >> looks good to me, too, overall and as it is active in our test system it proves to >> stabilize things. >> >> But, I agree to Bob in that you should rather define some constant like >> >> private static int EXIT_VALUE_INITIAL = -999; >> >> and use it to initialize and check pev. >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Mittwoch, 9. Oktober 2019 09:37 >>> To: Bob Vandette >>> Cc: hotspot-dev at openjdk.java.net; Langer, Christoph >>> ; MIKHAILO_SELEDTSOV >>> >>> Subject: RE: RFR: 8230957: [TESTBUG] >>> containers/docker/TestJcmdWithSideCar.java sporadic failures >>> >>> Hi Bob I changed the comment and renamed the variable to retryCount . >>> -999 is just an initialization and has no special meaning . >>> >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.2/ >>> >>> Best regards, Matthias >>> >>> >>>> I don?t think it?s necessary to state the obvious here: >>>> >>>> 59 private static final long >> TIME_TO_WAIT_FOR_MAIN_METHOD_START >>> = >>>> 50 * 1000; // milliseconds; increase 5 to 50 >>>> >>>> Where does this -999 come from? Is this documented anywhere? If so >>>> please define a constant. Would this >>>> work with podman? >>>> >>>> 237 int pev = -999; >>>> >>>> Could you give this a more descriptive name (retryCount maybe)? >>>> >>>> 238 int rt = 3; >>>> >>>> >>>> Bob. >>>> >>>> >>>>> On Oct 8, 2019, at 7:16 AM, Baesken, Matthias >>>> wrote: >>>>> Hello, please review the following test related change . >>>>> >>>>> The test containers/docker/TestJcmdWithSideCar.java has been >>>> reactivated after >>>>> https://bugs.openjdk.java.net/browse/JDK-8228960 >>>>> >>>>> and we see now sporadic failures. >>>>> >>>>> We needed to increase/adjust the timeouts and also check the Xmx >>> setting >>>> going into the java calls in the docker containers (we might inherit when >>> from >>>> the test java opts). >>>>> Also a bit more output has been added to the tests to better >> understand >>>> potential issues . >>>>> >>>>> Bug/webrev : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8230957 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8230957.1/ >>>>> >>>>> >>>>> Thanks, Matthias From lois.foltan at oracle.com Thu Oct 10 17:30:40 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 10 Oct 2019 13:30:40 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> Message-ID: On 10/9/2019 8:14 PM, David Holmes wrote: > Hi Lois, > > On 10/10/2019 7:18 am, Lois Foltan wrote: >> Please review this enhancement to consistently use the >> JVM_SIGNATURE_* constants for type signature processing.? This change >> is a precursor to JDK-8230199: consolidate signature parsing in >> Hotspot sources. >> >> open webrev >> at:http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.0/webrev/ >> >> bug link: https://bugs.openjdk.java.net/browse/JDK-8231844 >> contributed-by: Lois Foltan, John Rose > > In general the change is good - special characters should be referred > to by symbolic names to give more semantic context where practical. Thanks David for the review!? See my comments below.? New webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.1/webrev/ > > However I do have a few comments. > > It seems redundant and somewhat counter to the fix to change a > character in the code to a symbolic constant but then have a comment > still use the original character. Sometimes this seems acceptable as > it helps clarity e.g. > > ??? // Ignore wrapping L and ; > !?? if (name[0] == JVM_SIGNATURE_CLASS) { > > but in particular I found the comments here unnecessary: > > src/hotspot/share/utilities/globalDefinitions.cpp > > ?// Map BasicType to signature character > ! char type2char_tab[T_CONFLICT+1] = { > !?? 0, 0, 0, 0, > !?? JVM_SIGNATURE_BOOLEAN, JVM_SIGNATURE_CHAR,??? // 4:? 'Z', 'C' > !?? JVM_SIGNATURE_FLOAT,?? JVM_SIGNATURE_DOUBLE,? //???? 'F', 'D' > !?? JVM_SIGNATURE_BYTE,??? JVM_SIGNATURE_SHORT,?? // 8:? 'B', 'S' > !?? JVM_SIGNATURE_INT,???? JVM_SIGNATURE_LONG,??? //???? 'I', 'J' > !?? JVM_SIGNATURE_CLASS,?? JVM_SIGNATURE_ARRAY,?? // 12: 'L', '[' > !?? JVM_SIGNATURE_VOID,??? 0,???????????????????? //???? 'V' > !?? 0, 0, 0, 0 > ! }; > > other cases could go either way. Fixed this in utilities/globalDefinitions.cpp and another instance in src/hotspot/share/runtime/fieldType.cpp where the comments seemed redundant. > > --- > > src/java.base/share/native/include/classfile_constants.h.template > > +???? JVM_SIGNATURE_ENDPACKAGE??? = '/', > +???? JVM_SIGNATURE_ENDPACKAGE_DOT = '.', > > These constants bothered me both because of their very long names and > because the names aren't completely accurate. They both indicate > separators between identifiers: one for internal form, and one for > external form. The / doesn't "end a package" and . can be part of a > nested type name, unrelated to packages. As these characters do not > have a unique semantic usage that is easily expressed, perhaps > referring to them as just: > > JVM_SIGNATURE_SLASH > JVM_SIGNATURE_DOT > > would suffice? I agree, changed. > > --- > > src/hotspot/share/c1/c1_InstructionPrinter.cpp > > Should type2name really handle all cases and assert if an invalid > type, and return "???" (or perhaps "") in product mode? A new RFE should be created for addressing how type2name should handle an invalid type since it is used quite frequently throughout the JVM.? It is not in the scope of this RFE to change the behavior of type2name.? It was the goal to reduce the use of hard coded characters and/or strings when dealing with types and type signatures which is what the use of type2name does in InstructionPrinter::basic_type_name(). > > --- > > src/hotspot/share/utilities/globalDefinitions.hpp > > I do not like this new method: > > +inline BasicType primitive_or_object(BasicType t) { > +? assert(is_java_type(t), "%d", (int)t); > +? return (is_reference_type(t) ? T_OBJECT : t); > +} > > I found it's use in the code was far less clear than the original > code. I like to explicitly see where arrays and objects are being > treated the same (or differently). This is in line with the change that I recently completed for JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type.? Please refer to John's response to Coleen's review comment that I believe addresses your concern as well. https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html Thanks, Lois > > Thanks, > David > ----- > >> Testing: hs-tier1-3, jdk-tier1-2 (all platforms).? hs-tier4-6 (linux >> only) >> >> Thanks, >> Lois From christoph.langer at sap.com Thu Oct 10 21:36:24 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 21:36:24 +0000 Subject: RFR [XS] : 8232060: add some initializations using sigemptyset in os_aix.cpp In-Reply-To: References: Message-ID: +1 /Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Thomas St?fe > Sent: Donnerstag, 10. Oktober 2019 12:21 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS] : 8232060: add some initializations using sigemptyset in > os_aix.cpp > > Hi Matthias, > > looks good and trivial. +1. > > ..Thomas > > On Thu, Oct 10, 2019 at 9:42 AM Baesken, Matthias > > wrote: > > > Hello, please review the following small patch . > > > > Currently a couple of initializations with sigemptyset are missing in > > os_aix.cpp, that are done in os_linux . > > Usually the missing sigemptyset calls should not be a problem, however in > > special cases (e.g. very seldom failing pthread_* calls later in the > > coding) they > > might lead to uninitialized sigset_t structs used . > > > > > > Bug/wevrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8232060 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232060.0/ > > > > > > Thanks, Matthias > > From kim.barrett at oracle.com Thu Oct 10 23:43:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Oct 2019 19:43:16 -0400 Subject: RFR: 8232147: Remove notproduct option IgnoreLockingAssertions Message-ID: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> Please review this change to remove the IgnoreLockingAssertions option. CR: https://bugs.openjdk.java.net/browse/JDK-8232147 Webrev: https://cr.openjdk.java.net/~kbarrett/8232147/open.00/ Testing: mach5 tier1 From coleen.phillimore at oracle.com Thu Oct 10 23:51:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 10 Oct 2019 19:51:08 -0400 Subject: RFR: 8232147: Remove notproduct option IgnoreLockingAssertions In-Reply-To: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> References: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> Message-ID: <44cb26ee-b0a6-9b1f-7313-7aa97f7dadbb@oracle.com> Looks good! Coleen On 10/10/19 7:43 PM, Kim Barrett wrote: > Please review this change to remove the IgnoreLockingAssertions option. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8232147 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8232147/open.00/ > > Testing: > mach5 tier1 > > From kim.barrett at oracle.com Thu Oct 10 23:59:05 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Oct 2019 19:59:05 -0400 Subject: RFR: 8232147: Remove notproduct option IgnoreLockingAssertions In-Reply-To: <44cb26ee-b0a6-9b1f-7313-7aa97f7dadbb@oracle.com> References: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> <44cb26ee-b0a6-9b1f-7313-7aa97f7dadbb@oracle.com> Message-ID: <5D12D1EA-3005-49BF-A9E5-3731DD36F32E@oracle.com> > On Oct 10, 2019, at 7:51 PM, coleen.phillimore at oracle.com wrote: > > Looks good! > Coleen Thanks. > On 10/10/19 7:43 PM, Kim Barrett wrote: >> Please review this change to remove the IgnoreLockingAssertions option. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8232147 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8232147/open.00/ >> >> Testing: >> mach5 tier1 From david.holmes at oracle.com Fri Oct 11 00:30:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2019 10:30:07 +1000 Subject: RFR: 8232147: Remove notproduct option IgnoreLockingAssertions In-Reply-To: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> References: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> Message-ID: <1f900010-2c2c-4b36-f03f-547583f76050@oracle.com> LGTM! Thanks, David On 11/10/2019 9:43 am, Kim Barrett wrote: > Please review this change to remove the IgnoreLockingAssertions option. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8232147 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8232147/open.00/ > > Testing: > mach5 tier1 > > From david.holmes at oracle.com Fri Oct 11 01:15:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2019 11:15:57 +1000 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> Message-ID: <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> Hi Lois, On 11/10/2019 3:30 am, Lois Foltan wrote: > On 10/9/2019 8:14 PM, David Holmes wrote: >> Hi Lois, >> >> On 10/10/2019 7:18 am, Lois Foltan wrote: >>> Please review this enhancement to consistently use the >>> JVM_SIGNATURE_* constants for type signature processing.? This change >>> is a precursor to JDK-8230199: consolidate signature parsing in >>> Hotspot sources. >>> >>> open webrev >>> at:http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.0/webrev/ >>> >>> bug link: https://bugs.openjdk.java.net/browse/JDK-8231844 >>> contributed-by: Lois Foltan, John Rose >> >> In general the change is good - special characters should be referred >> to by symbolic names to give more semantic context where practical. > > Thanks David for the review!? See my comments below.? New webrev at: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.1/webrev/ Updated look good - thanks. Follow up comments way below ... >> >> However I do have a few comments. >> >> It seems redundant and somewhat counter to the fix to change a >> character in the code to a symbolic constant but then have a comment >> still use the original character. Sometimes this seems acceptable as >> it helps clarity e.g. >> >> ??? // Ignore wrapping L and ; >> !?? if (name[0] == JVM_SIGNATURE_CLASS) { >> >> but in particular I found the comments here unnecessary: >> >> src/hotspot/share/utilities/globalDefinitions.cpp >> >> ?// Map BasicType to signature character >> ! char type2char_tab[T_CONFLICT+1] = { >> !?? 0, 0, 0, 0, >> !?? JVM_SIGNATURE_BOOLEAN, JVM_SIGNATURE_CHAR,??? // 4:? 'Z', 'C' >> !?? JVM_SIGNATURE_FLOAT,?? JVM_SIGNATURE_DOUBLE,? //???? 'F', 'D' >> !?? JVM_SIGNATURE_BYTE,??? JVM_SIGNATURE_SHORT,?? // 8:? 'B', 'S' >> !?? JVM_SIGNATURE_INT,???? JVM_SIGNATURE_LONG,??? //???? 'I', 'J' >> !?? JVM_SIGNATURE_CLASS,?? JVM_SIGNATURE_ARRAY,?? // 12: 'L', '[' >> !?? JVM_SIGNATURE_VOID,??? 0,???????????????????? //???? 'V' >> !?? 0, 0, 0, 0 >> ! }; >> >> other cases could go either way. > > Fixed this in utilities/globalDefinitions.cpp and another instance in > src/hotspot/share/runtime/fieldType.cpp where the comments seemed > redundant. > >> >> --- >> >> src/java.base/share/native/include/classfile_constants.h.template >> >> +???? JVM_SIGNATURE_ENDPACKAGE??? = '/', >> +???? JVM_SIGNATURE_ENDPACKAGE_DOT = '.', >> >> These constants bothered me both because of their very long names and >> because the names aren't completely accurate. They both indicate >> separators between identifiers: one for internal form, and one for >> external form. The / doesn't "end a package" and . can be part of a >> nested type name, unrelated to packages. As these characters do not >> have a unique semantic usage that is easily expressed, perhaps >> referring to them as just: >> >> JVM_SIGNATURE_SLASH >> JVM_SIGNATURE_DOT >> >> would suffice? > > I agree, changed. > >> >> --- >> >> src/hotspot/share/c1/c1_InstructionPrinter.cpp >> >> Should type2name really handle all cases and assert if an invalid >> type, and return "???" (or perhaps "") in product mode? > > A new RFE should be created for addressing how type2name should handle > an invalid type since it is used quite frequently throughout the JVM. It > is not in the scope of this RFE to change the behavior of type2name. It > was the goal to reduce the use of hard coded characters and/or strings > when dealing with types and type signatures which is what the use of > type2name does in InstructionPrinter::basic_type_name(). Agree this is out of scope. >> >> --- >> >> src/hotspot/share/utilities/globalDefinitions.hpp >> >> I do not like this new method: >> >> +inline BasicType primitive_or_object(BasicType t) { >> +? assert(is_java_type(t), "%d", (int)t); >> +? return (is_reference_type(t) ? T_OBJECT : t); >> +} >> >> I found it's use in the code was far less clear than the original >> code. I like to explicitly see where arrays and objects are being >> treated the same (or differently). > > This is in line with the change that I recently completed for > JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with > call to is_reference_type.? Please refer to John's response to Coleen's > review comment that I believe addresses your concern as well. > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html I can't say that I agree. A simple query like is_reference_type() is perfectly fine. But reducing all reference types to just T_OBJECT is something that, to me, needs to be consciously chosen when a new reference type is added. This approach could hide bugs as it will be easy to miss locations that might new to handle the new reference type differently. Just my 2c. Thanks, David > > Thanks, > Lois > >> >> Thanks, >> David >> ----- >> >>> Testing: hs-tier1-3, jdk-tier1-2 (all platforms).? hs-tier4-6 (linux >>> only) >>> >>> Thanks, >>> Lois > From kim.barrett at oracle.com Fri Oct 11 05:35:40 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Oct 2019 01:35:40 -0400 Subject: RFR: 8232147: Remove notproduct option IgnoreLockingAssertions In-Reply-To: <1f900010-2c2c-4b36-f03f-547583f76050@oracle.com> References: <4807CC96-9E26-4852-B7D9-9B6495A8CF22@oracle.com> <1f900010-2c2c-4b36-f03f-547583f76050@oracle.com> Message-ID: > On Oct 10, 2019, at 8:30 PM, David Holmes wrote: > > LGTM! > > Thanks, > David Thanks. > On 11/10/2019 9:43 am, Kim Barrett wrote: >> Please review this change to remove the IgnoreLockingAssertions option. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8232147 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8232147/open.00/ >> Testing: >> mach5 tier1 From erik.osterlund at oracle.com Fri Oct 11 09:00:01 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Fri, 11 Oct 2019 11:00:01 +0200 Subject: RFC: JEP JDK-8221828: New Invoke Bindings Message-ID: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Hi, I prepared a new JEP [1], about rewriting the method invocation mechanisms in HotSpot. In particular, the aim is to remove inline caches, in an effort to make our code more robust and maintainable (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, make redefinition and unloading much more straight forward). Instead, it is to be replaced with a table driven approach, leaving speculation machinery to the hardware instead of software. More details are in the JEP description. Feedback is more than welcome. Thanks, /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8221828 From stefan.reich.maker.of.eye at googlemail.com Fri Oct 11 11:02:01 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 11 Oct 2019 13:02:01 +0200 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Message-ID: > The proposal for invokevirtual calls is to flatten the vtable to have direct code pointers at a negative offset from the class pointer. This allows dispatching with a single indirect branch (compared to two direct branches for dynamically monomorphic calls today). Isn't that even independent from the rest of the proposal? Sounds like a smart thing to do. Would there be any downside to putting the vtable directly in the klass structure? Hey, we'd be back to Turbo Pascal speeds where the vtable WAS the class (I believe). Stefan On Fri, 11 Oct 2019 at 11:01, wrote: > > Hi, > > I prepared a new JEP [1], about rewriting the method invocation > mechanisms in HotSpot. In particular, the aim is to remove inline > caches, in an effort to make our code more robust and maintainable > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, > make redefinition and unloading much more straight forward). Instead, it > is to be replaced with a table driven approach, leaving speculation > machinery to the hardware instead of software. More details are in the > JEP description. > > Feedback is more than welcome. > > Thanks, > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8221828 -- Stefan Reich BotCompany.de // Java-based operating systems From vitalyd at gmail.com Fri Oct 11 11:24:02 2019 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Oct 2019 07:24:02 -0400 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Message-ID: Hi Erik, This sounds like a great idea! You touch on this in the JEP, but avoiding global safepoints for ICStub patching would be great. http://openjdk.5641.n7.nabble.com/InlineCacheBuffer-GuaranteedSafepointInterval-td229138.html is a few years old but I think largely still true today. How confident are you that hardware?s branch target buffer (BTB) will neutralize the loss of direct jumps? In large applications, with lots of code and deep call graphs, I?d be concerned that BTB is exhausted due to sheer number of entries needed. Of course this is just speculation. Thanks On Fri, Oct 11, 2019 at 5:03 AM wrote: > Hi, > > I prepared a new JEP [1], about rewriting the method invocation > mechanisms in HotSpot. In particular, the aim is to remove inline > caches, in an effort to make our code more robust and maintainable > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, > make redefinition and unloading much more straight forward). Instead, it > is to be replaced with a table driven approach, leaving speculation > machinery to the hardware instead of software. More details are in the > JEP description. > > Feedback is more than welcome. > > Thanks, > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8221828 > -- Sent from my phone From erik.osterlund at oracle.com Fri Oct 11 11:24:27 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Fri, 11 Oct 2019 13:24:27 +0200 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Message-ID: <29d3f749-72cd-cf2c-9073-e7c20c25c839@oracle.com> Hi Stefan, On 10/11/19 1:02 PM, Stefan Reich wrote: > ?> The proposal for invokevirtual calls is to flatten the vtable to > have direct code pointers at a negative offset from the class pointer. > This allows dispatching with a single indirect branch (compared to two > direct branches for dynamically monomorphic calls today). > > Isn't that even independent from the rest of the proposal? Sounds like > a smart thing to do. Would there be any downside to putting the vtable > directly in the klass structure? The vtable is already embedded into Klass instances today. However, given a base pointer, you have the ability to address at most two dynamically sized data structures with statically known offsets from that base pointer; one data structure at a negative offset from the base pointer, and one at a positive offset. Today, both the vtable and itable have positive offsets from the base pointers, hence there is a dynamically loaded offset to one of the two. Vtable has been chosen to claim that static offset, while itable offsets are dynamically looked up, which I guess makes sense because such itable dispatching is already quite inefficient today (linearly walking itables twice among other things). The idea of putting one of them at a negative offset, could indeed be done with today's data structures as well. Having said that, today's inline cache dispatching mechanism is less reliant on the megamorphic bindings that perform table lookup are fast. The inline caches exist to hide the poor performance of megamorphic calls, by speculating that they are monomorphic. Most are indeed dynamically monomorphic, and then no table lookups are performed. My approach is to dodge the type speculation machinery and instead optimize the megamorphic call mechanism (by optimizing the data structures they use) so that the reliance on speculation for monomorphic call performance is significantly less. That's why it makes sense with my approach to perform more data structure optimizations than makes sense with the mechanism we have today. Because I expose all callsites to potentially megamorphic calls, leaving the monomorphic speculation trick to the branch target buffering mechanisms that hardware has become so good at. /Erik > Hey, we'd be back to Turbo Pascal speeds where the vtable WAS the > class (I believe). > > Stefan > > On Fri, 11 Oct 2019 at 11:01, > wrote: > > > > Hi, > > > > I prepared a new JEP [1], about rewriting the method invocation > > mechanisms in HotSpot. In particular, the aim is to remove inline > > caches, in an effort to make our code more robust and maintainable > > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, > > make redefinition and unloading much more straight forward). Instead, it > > is to be replaced with a table driven approach, leaving speculation > > machinery to the hardware instead of software. More details are in the > > JEP description. > > > > Feedback is more than welcome. > > > > Thanks, > > /Erik > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8221828 > > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Fri Oct 11 11:26:26 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 11 Oct 2019 13:26:26 +0200 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: <29d3f749-72cd-cf2c-9073-e7c20c25c839@oracle.com> References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> <29d3f749-72cd-cf2c-9073-e7c20c25c839@oracle.com> Message-ID: Hi Erik, I understand, thanks for the explanation. Sounds reasonable. On Fri, 11 Oct 2019 at 13:24, wrote: > Hi Stefan, > > On 10/11/19 1:02 PM, Stefan Reich wrote: > > > The proposal for invokevirtual calls is to flatten the vtable to have > direct code pointers at a negative offset from the class pointer. This > allows dispatching with a single indirect branch (compared to two direct > branches for dynamically monomorphic calls today). > > Isn't that even independent from the rest of the proposal? Sounds like a > smart thing to do. Would there be any downside to putting the vtable > directly in the klass structure? > > > The vtable is already embedded into Klass instances today. However, given > a base pointer, you have the ability to address at most two dynamically > sized data structures with statically known offsets from that base pointer; > one data structure at a negative offset from the base pointer, and one at a > positive offset. Today, both the vtable and itable have positive offsets > from the base pointers, hence there is a dynamically loaded offset to one > of the two. Vtable has been chosen to claim that static offset, while > itable offsets are dynamically looked up, which I guess makes sense because > such itable dispatching is already quite inefficient today (linearly > walking itables twice among other things). The idea of putting one of them > at a negative offset, could indeed be done with today's data structures as > well. > > Having said that, today's inline cache dispatching mechanism is less > reliant on the megamorphic bindings that perform table lookup are fast. The > inline caches exist to hide the poor performance of megamorphic calls, by > speculating that they are monomorphic. Most are indeed dynamically > monomorphic, and then no table lookups are performed. My approach is to > dodge the type speculation machinery and instead optimize the megamorphic > call mechanism (by optimizing the data structures they use) so that the > reliance on speculation for monomorphic call performance is significantly > less. That's why it makes sense with my approach to perform more data > structure optimizations than makes sense with the mechanism we have today. > Because I expose all callsites to potentially megamorphic calls, leaving > the monomorphic speculation trick to the branch target buffering mechanisms > that hardware has become so good at. > > /Erik > > Hey, we'd be back to Turbo Pascal speeds where the vtable WAS the class (I > believe). > > Stefan > > On Fri, 11 Oct 2019 at 11:01, wrote: > > > > Hi, > > > > I prepared a new JEP [1], about rewriting the method invocation > > mechanisms in HotSpot. In particular, the aim is to remove inline > > caches, in an effort to make our code more robust and maintainable > > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, > > make redefinition and unloading much more straight forward). Instead, it > > is to be replaced with a table driven approach, leaving speculation > > machinery to the hardware instead of software. More details are in the > > JEP description. > > > > Feedback is more than welcome. > > > > Thanks, > > /Erik > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8221828 > > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems > > > -- Stefan Reich BotCompany.de // Java-based operating systems From erik.osterlund at oracle.com Fri Oct 11 11:50:15 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Fri, 11 Oct 2019 13:50:15 +0200 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Message-ID: Hi Vitaly, On 10/11/19 1:24 PM, Vitaly Davidovich wrote: > Hi Erik, > > This sounds like a great idea! You touch on this in the JEP, but > avoiding global safepoints for ICStub patching would be great. > http://openjdk.5641.n7.nabble.com/InlineCacheBuffer-GuaranteedSafepointInterval-td229138.html > is a few years old but I think largely still true today. Glad you brought this up. Yes. In fact, this is how this whole thing started for me. When I implemented concurrent class unloading for ZGC back in JDK 12, I found it quite annoying that our concurrent inline cache cleaning may trigger safepoints. I measured that after cleaning ~140 IC stubs (due to a rather pessimistic buffer sizing), we would run out of buffer space and safepoint. Since I work in the ZGC project, I get irrationally upset when I see things being done in safepoints that don't need it, and am willing to walk very far to get rid of them. So I started looking into whether these IC stubs can be freed concurrently instead. I implemented a pipelined three-phased global handshaking scheme for safely reclaiming IC stubs and CompiledICHolders concurrently in the service thread, on architectures that support instruction cache coherency, which remedied the safepointing problem on x86_64. But not all architectures have instruction cache coherency, so I was annoyed by the limited portability of my solution, and maintaining multiple different life cycles of IC stubs, and making inline caches even more complicated than they already are. That's when I had finally had enough of inline cache problems, shelved that idea and decided to instead get rid of inline caches, as they no longer seem to solve a problem that is current, yet cause headache on a daily basis. > How confident are you that hardware?s branch target buffer (BTB) will > neutralize the loss of direct jumps? In large applications, with lots > of code and deep call graphs, I?d be concerned that BTB is exhausted > due to sheer number of entries needed. I have run a bunch of workloads (some very code cache heavy), even without inlining to stress the dispatching mechanism more than reasonable, without observing any noticeable differences with my new mechanism compared to the old mechanism. So I am fairly optimistic at this point. What I have been fighting more with is start-up performance. I generate special unique numbers for each Method*, which stresses startup performance surprisingly much. But I am happy with where that is at right now after throwing a bunch of tricks on that code. Having said that, I am still in a prototyping phase, and have more evaluation to be done, and will of course have a close look at how that pans out. > Of course this is just speculation. ...I see what you did there. /Erik > > Thanks > > On Fri, Oct 11, 2019 at 5:03 AM > wrote: > > Hi, > > I prepared a new JEP [1], about rewriting the method invocation > mechanisms in HotSpot. In particular, the aim is to remove inline > caches, in an effort to make our code more robust and maintainable > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, > make redefinition and unloading much more straight forward). > Instead, it > is to be replaced with a table driven approach, leaving speculation > machinery to the hardware instead of software. More details are in > the > JEP description. > > Feedback is more than welcome. > > Thanks, > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8221828 > > -- > Sent from my phone From vitalyd at gmail.com Fri Oct 11 12:09:22 2019 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Oct 2019 08:09:22 -0400 Subject: RFC: JEP JDK-8221828: New Invoke Bindings In-Reply-To: References: <5c7b0666-71e2-b200-d47f-abb9bb8e7a75@oracle.com> Message-ID: On Fri, Oct 11, 2019 at 7:52 AM wrote: > Hi Vitaly, > > On 10/11/19 1:24 PM, Vitaly Davidovich wrote: > > Hi Erik, > > This sounds like a great idea! You touch on this in the JEP, but avoiding > global safepoints for ICStub patching would be great. > > http://openjdk.5641.n7.nabble.com/InlineCacheBuffer-GuaranteedSafepointInterval-td229138.html > is a few years old but I think largely still true today. > > > Glad you brought this up. Yes. In fact, this is how this whole thing > started for me. When I implemented concurrent class unloading for ZGC back > in JDK 12, I found it quite annoying that our concurrent inline cache > cleaning may trigger safepoints. I measured that after cleaning ~140 IC > stubs (due to a rather pessimistic buffer sizing), we would run out of > buffer space and safepoint. Since I work in the ZGC project, I get > irrationally upset when I see things being done in safepoints that don't > need it, and am willing to walk very far to get rid of them. > We need more Eriks! :) > So I started looking into whether these IC stubs can be freed concurrently > instead. I implemented a pipelined three-phased global handshaking scheme > for safely reclaiming IC stubs and CompiledICHolders concurrently in the > service thread, on architectures that support instruction cache coherency, > which remedied the safepointing problem on x86_64. But not all > architectures have instruction cache coherency, so I was annoyed by the > limited portability of my solution, and maintaining multiple different life > cycles of IC stubs, and making inline caches even more complicated than > they already are. That's when I had finally had enough of inline cache > problems, shelved that idea and decided to instead get rid of inline > caches, as they no longer seem to solve a problem that is current, yet > cause headache on a daily basis. > Impressive, and kudos for not walking away from this complexity. > > > How confident are you that hardware?s branch target buffer (BTB) will > neutralize the loss of direct jumps? In large applications, with lots of > code and deep call graphs, I?d be concerned that BTB is exhausted due to > sheer number of entries needed. > > > I have run a bunch of workloads (some very code cache heavy), even without > inlining to stress the dispatching mechanism more than reasonable, without > observing any noticeable differences with my new mechanism compared to the > old mechanism. So I am fairly optimistic at this point. What I have been > fighting more with is start-up performance. I generate special unique > numbers for each Method*, which stresses startup performance surprisingly > much. But I am happy with where that is at right now after throwing a bunch > of tricks on that code. Having said that, I am still in a prototyping > phase, and have more evaluation to be done, and will of course have a close > look at how that pans out. > Sounds great. Look forward to hearing more as you make progress. > > > Of course this is just speculation. > > > ...I see what you did there. > :) > > /Erik > > > Thanks > > On Fri, Oct 11, 2019 at 5:03 AM wrote: > >> Hi, >> >> I prepared a new JEP [1], about rewriting the method invocation >> mechanisms in HotSpot. In particular, the aim is to remove inline >> caches, in an effort to make our code more robust and maintainable >> (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff, >> make redefinition and unloading much more straight forward). Instead, it >> is to be replaced with a table driven approach, leaving speculation >> machinery to the hardware instead of software. More details are in the >> JEP description. >> >> Feedback is more than welcome. >> >> Thanks, >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8221828 >> > -- > Sent from my phone > > > From frederic.parain at oracle.com Fri Oct 11 12:29:13 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 11 Oct 2019 08:29:13 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> Message-ID: <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> > On Oct 10, 2019, at 21:15, David Holmes wrote: >>> >>> --- >>> >>> src/hotspot/share/utilities/globalDefinitions.hpp >>> >>> I do not like this new method: >>> >>> +inline BasicType primitive_or_object(BasicType t) { >>> + assert(is_java_type(t), "%d", (int)t); >>> + return (is_reference_type(t) ? T_OBJECT : t); >>> +} >>> >>> I found it's use in the code was far less clear than the original code. I like to explicitly see where arrays and objects are being treated the same (or differently). >> This is in line with the change that I recently completed for JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type. Please refer to John's response to Coleen's review comment that I believe addresses your concern as well. https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html > > I can't say that I agree. A simple query like is_reference_type() is perfectly fine. But reducing all reference types to just T_OBJECT is something that, to me, needs to be consciously chosen when a new reference type is added. This approach could hide bugs as it will be easy to miss locations that might new to handle the new reference type differently. Just my 2c. I agree with David here. 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to T_OBJECT can be a source of confusion because each time we see T_OBJECT in the source code, we don?t know if it means T_OBJECT only or all reference types. 2 - the name of the method ?primitive_or_object()? is confusing too, its meaning is not obvious and it doesn?t sound like a conversion method (which it is) Would it be possible to have an internal T_REFERENCE type to clearly indicate erased reference types? The use of a T_REFERENCE case in a switch statement would clearly indicate that the case applies to all reference types. Then the method could be renamed: as_primitive_or_REFERENCE() which I believe makes the conversion more explicit. My 2c. Fred From matthias.baesken at sap.com Fri Oct 11 14:20:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 11 Oct 2019 14:20:20 +0000 Subject: RFR: 8232107: support ThreadPriorityPolicy flag on AIX Message-ID: Hello, please review the following small change . It adds support for the ThreadPriorityPolicy flag on AIX (and brings the implementation in os_aix closer to what we have in os_linux ). While ThreadPriorityPolicy is an "old" flag, we have some customers using it so it would be nice to support it on all UNIX platforms . Bug / webrev : https://bugs.openjdk.java.net/browse/JDK-8232107 http://cr.openjdk.java.net/~mbaesken/webrevs/8232107.0/ Best regards, Matthias From lois.foltan at oracle.com Fri Oct 11 19:32:47 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 11 Oct 2019 15:32:47 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> Message-ID: <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> On 10/11/2019 8:29 AM, Frederic Parain wrote: > >> On Oct 10, 2019, at 21:15, David Holmes wrote: >>>> --- >>>> >>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>> >>>> I do not like this new method: >>>> >>>> +inline BasicType primitive_or_object(BasicType t) { >>>> + assert(is_java_type(t), "%d", (int)t); >>>> + return (is_reference_type(t) ? T_OBJECT : t); >>>> +} >>>> >>>> I found it's use in the code was far less clear than the original code. I like to explicitly see where arrays and objects are being treated the same (or differently). >>> This is in line with the change that I recently completed for JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type. Please refer to John's response to Coleen's review comment that I believe addresses your concern as well. https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >> I can't say that I agree. A simple query like is_reference_type() is perfectly fine. But reducing all reference types to just T_OBJECT is something that, to me, needs to be consciously chosen when a new reference type is added. This approach could hide bugs as it will be easy to miss locations that might new to handle the new reference type differently. Just my 2c. > I agree with David here. > 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to T_OBJECT can be a source > of confusion because each time we see T_OBJECT in the source code, we don?t know if it > means T_OBJECT only or all reference types. > 2 - the name of the method ?primitive_or_object()? is confusing too, its meaning is not obvious > and it doesn?t sound like a conversion method (which it is) > > Would it be possible to have an internal T_REFERENCE type to clearly indicate erased reference types? > The use of a T_REFERENCE case in a switch statement would clearly indicate that the case applies > to all reference types. > Then the method could be renamed: as_primitive_or_REFERENCE() which I believe makes the conversion > more explicit. > > My 2c. Thank you Fred for reviewing this change and your 2c!? Given both you and David make valid points, it seems obvious more discussion is warranted concerning specifically primitive_or_object().? So, I have removed that from this change and have posted a new webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ The change is now just limited to changing the hard coded literals to JVM_SIGNATURE_*. Thanks, Lois > > Fred > > > > From lois.foltan at oracle.com Fri Oct 11 19:36:52 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 11 Oct 2019 15:36:52 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> Message-ID: On 10/10/2019 9:15 PM, David Holmes wrote: > Hi Lois, > > On 11/10/2019 3:30 am, Lois Foltan wrote: >> On 10/9/2019 8:14 PM, David Holmes wrote: >>> Hi Lois, >>> >>> On 10/10/2019 7:18 am, Lois Foltan wrote: >>>> Please review this enhancement to consistently use the >>>> JVM_SIGNATURE_* constants for type signature processing.? This >>>> change is a precursor to JDK-8230199: consolidate signature parsing >>>> in Hotspot sources. >>>> >>>> open webrev >>>> at:http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.0/webrev/ >>>> >>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8231844 >>>> contributed-by: Lois Foltan, John Rose >>> >>> In general the change is good - special characters should be >>> referred to by symbolic names to give more semantic context where >>> practical. >> >> Thanks David for the review!? See my comments below.? New webrev at: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.1/webrev/ > > Updated look good - thanks. > > Follow up comments way below ... > >>> >>> However I do have a few comments. >>> >>> It seems redundant and somewhat counter to the fix to change a >>> character in the code to a symbolic constant but then have a comment >>> still use the original character. Sometimes this seems acceptable as >>> it helps clarity e.g. >>> >>> ??? // Ignore wrapping L and ; >>> !?? if (name[0] == JVM_SIGNATURE_CLASS) { >>> >>> but in particular I found the comments here unnecessary: >>> >>> src/hotspot/share/utilities/globalDefinitions.cpp >>> >>> ?// Map BasicType to signature character >>> ! char type2char_tab[T_CONFLICT+1] = { >>> !?? 0, 0, 0, 0, >>> !?? JVM_SIGNATURE_BOOLEAN, JVM_SIGNATURE_CHAR,??? // 4:? 'Z', 'C' >>> !?? JVM_SIGNATURE_FLOAT,?? JVM_SIGNATURE_DOUBLE,? //???? 'F', 'D' >>> !?? JVM_SIGNATURE_BYTE,??? JVM_SIGNATURE_SHORT,?? // 8:? 'B', 'S' >>> !?? JVM_SIGNATURE_INT,???? JVM_SIGNATURE_LONG,??? //???? 'I', 'J' >>> !?? JVM_SIGNATURE_CLASS,?? JVM_SIGNATURE_ARRAY,?? // 12: 'L', '[' >>> !?? JVM_SIGNATURE_VOID,??? 0,???????????????????? //???? 'V' >>> !?? 0, 0, 0, 0 >>> ! }; >>> >>> other cases could go either way. >> >> Fixed this in utilities/globalDefinitions.cpp and another instance in >> src/hotspot/share/runtime/fieldType.cpp where the comments seemed >> redundant. >> >>> >>> --- >>> >>> src/java.base/share/native/include/classfile_constants.h.template >>> >>> +???? JVM_SIGNATURE_ENDPACKAGE??? = '/', >>> +???? JVM_SIGNATURE_ENDPACKAGE_DOT = '.', >>> >>> These constants bothered me both because of their very long names >>> and because the names aren't completely accurate. They both indicate >>> separators between identifiers: one for internal form, and one for >>> external form. The / doesn't "end a package" and . can be part of a >>> nested type name, unrelated to packages. As these characters do not >>> have a unique semantic usage that is easily expressed, perhaps >>> referring to them as just: >>> >>> JVM_SIGNATURE_SLASH >>> JVM_SIGNATURE_DOT >>> >>> would suffice? >> >> I agree, changed. >> >>> >>> --- >>> >>> src/hotspot/share/c1/c1_InstructionPrinter.cpp >>> >>> Should type2name really handle all cases and assert if an invalid >>> type, and return "???" (or perhaps "") in product mode? >> >> A new RFE should be created for addressing how type2name should >> handle an invalid type since it is used quite frequently throughout >> the JVM. It is not in the scope of this RFE to change the behavior of >> type2name. It was the goal to reduce the use of hard coded characters >> and/or strings when dealing with types and type signatures which is >> what the use of type2name does in InstructionPrinter::basic_type_name(). > > Agree this is out of scope. > >>> >>> --- >>> >>> src/hotspot/share/utilities/globalDefinitions.hpp >>> >>> I do not like this new method: >>> >>> +inline BasicType primitive_or_object(BasicType t) { >>> +? assert(is_java_type(t), "%d", (int)t); >>> +? return (is_reference_type(t) ? T_OBJECT : t); >>> +} >>> >>> I found it's use in the code was far less clear than the original >>> code. I like to explicitly see where arrays and objects are being >>> treated the same (or differently). >> >> This is in line with the change that I recently completed for >> JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY >> with call to is_reference_type.? Please refer to John's response to >> Coleen's review comment that I believe addresses your concern as >> well. >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html > > > I can't say that I agree. A simple query like is_reference_type() is > perfectly fine. But reducing all reference types to just T_OBJECT is > something that, to me, needs to be consciously chosen when a new > reference type is added. This approach could hide bugs as it will be > easy to miss locations that might new to handle the new reference type > differently. Just my 2c. Thanks David for your 2c.? Based on your and Fred's feedback I have posted a new webrev without the change to primitive_or_object() since more discussion is needed.? See new webrev link in my reply to Fred. Lois > > Thanks, > David > >> >> Thanks, >> Lois >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> Testing: hs-tier1-3, jdk-tier1-2 (all platforms).? hs-tier4-6 >>>> (linux only) >>>> >>>> Thanks, >>>> Lois >> From coleen.phillimore at oracle.com Fri Oct 11 20:34:09 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 11 Oct 2019 16:34:09 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> Message-ID: <7c18dbf4-0096-2e49-b173-34bb881a2253@oracle.com> http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/src/hotspot/share/runtime/signature.cpp.udiff.html The spacing style at the top is really weird.? Can you fix it before pushing? Otherwise looks good! Coleen On 10/11/19 3:32 PM, Lois Foltan wrote: > On 10/11/2019 8:29 AM, Frederic Parain wrote: >> >>> On Oct 10, 2019, at 21:15, David Holmes >>> wrote: >>>>> --- >>>>> >>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>> >>>>> I do not like this new method: >>>>> >>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>> +? assert(is_java_type(t), "%d", (int)t); >>>>> +? return (is_reference_type(t) ? T_OBJECT : t); >>>>> +} >>>>> >>>>> I found it's use in the code was far less clear than the original >>>>> code. I like to explicitly see where arrays and objects are being >>>>> treated the same (or differently). >>>> This is in line with the change that I recently completed for >>>> JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY >>>> with call to is_reference_type.? Please refer to John's response to >>>> Coleen's review comment that I believe addresses your concern as >>>> well. >>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>> I can't say that I agree. A simple query like is_reference_type() is >>> perfectly fine. But reducing all reference types to just T_OBJECT is >>> something that, to me, needs to be consciously chosen when a new >>> reference type is added. This approach could hide bugs as it will be >>> easy to miss locations that might new to handle the new reference >>> type differently. Just my 2c. >> I agree with David here. >> ? 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to >> T_OBJECT can be a source >> ????? of confusion because each time we see T_OBJECT in the source >> code, we don?t know if it >> ????? means T_OBJECT only or all reference types. >> ? 2 - the name of the method ?primitive_or_object()? is confusing >> too, its meaning is not obvious >> ????? and it doesn?t sound like a conversion method (which it is) >> >> Would it be possible to have an internal T_REFERENCE type to clearly >> indicate erased reference types? >> The use of a T_REFERENCE case in a switch statement would clearly >> indicate that the case applies >> to all reference types. >> Then the method could be renamed: as_primitive_or_REFERENCE() which I >> believe makes the conversion >> more explicit. >> >> My 2c. > > Thank you Fred for reviewing this change and your 2c!? Given both you > and David make valid points, it seems obvious more discussion is > warranted concerning specifically primitive_or_object().? So, I have > removed that from this change and have posted a new webrev at: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ > > The change is now just limited to changing the hard coded literals to > JVM_SIGNATURE_*. > > Thanks, > Lois > >> >> Fred >> >> >> >> > From lois.foltan at oracle.com Fri Oct 11 21:15:11 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 11 Oct 2019 17:15:11 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <7c18dbf4-0096-2e49-b173-34bb881a2253@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> <7c18dbf4-0096-2e49-b173-34bb881a2253@oracle.com> Message-ID: <9405052d-9b03-593f-37e8-6d72629bf74e@oracle.com> On 10/11/2019 4:34 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/src/hotspot/share/runtime/signature.cpp.udiff.html > > > The spacing style at the top is really weird.? Can you fix it before > pushing? > > Otherwise looks good! Thanks Coleen for the review!? Will fix that spacing style in signature.cpp before pushing. Lois > Coleen > > On 10/11/19 3:32 PM, Lois Foltan wrote: >> On 10/11/2019 8:29 AM, Frederic Parain wrote: >>> >>>> On Oct 10, 2019, at 21:15, David Holmes >>>> wrote: >>>>>> --- >>>>>> >>>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>>> >>>>>> I do not like this new method: >>>>>> >>>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>>> +? assert(is_java_type(t), "%d", (int)t); >>>>>> +? return (is_reference_type(t) ? T_OBJECT : t); >>>>>> +} >>>>>> >>>>>> I found it's use in the code was far less clear than the original >>>>>> code. I like to explicitly see where arrays and objects are being >>>>>> treated the same (or differently). >>>>> This is in line with the change that I recently completed for >>>>> JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY >>>>> with call to is_reference_type.? Please refer to John's response >>>>> to Coleen's review comment that I believe addresses your concern >>>>> as well. >>>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>>> I can't say that I agree. A simple query like is_reference_type() >>>> is perfectly fine. But reducing all reference types to just >>>> T_OBJECT is something that, to me, needs to be consciously chosen >>>> when a new reference type is added. This approach could hide bugs >>>> as it will be easy to miss locations that might new to handle the >>>> new reference type differently. Just my 2c. >>> I agree with David here. >>> ? 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) >>> to T_OBJECT can be a source >>> ????? of confusion because each time we see T_OBJECT in the source >>> code, we don?t know if it >>> ????? means T_OBJECT only or all reference types. >>> ? 2 - the name of the method ?primitive_or_object()? is confusing >>> too, its meaning is not obvious >>> ????? and it doesn?t sound like a conversion method (which it is) >>> >>> Would it be possible to have an internal T_REFERENCE type to clearly >>> indicate erased reference types? >>> The use of a T_REFERENCE case in a switch statement would clearly >>> indicate that the case applies >>> to all reference types. >>> Then the method could be renamed: as_primitive_or_REFERENCE() which >>> I believe makes the conversion >>> more explicit. >>> >>> My 2c. >> >> Thank you Fred for reviewing this change and your 2c!? Given both you >> and David make valid points, it seems obvious more discussion is >> warranted concerning specifically primitive_or_object().? So, I have >> removed that from this change and have posted a new webrev at: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ >> >> The change is now just limited to changing the hard coded literals to >> JVM_SIGNATURE_*. >> >> Thanks, >> Lois >> >>> >>> Fred >>> >>> >>> >>> >> > From david.holmes at oracle.com Fri Oct 11 23:04:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Oct 2019 09:04:19 +1000 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> Message-ID: Thanks Lois LGTM. David On 12/10/2019 5:32 am, Lois Foltan wrote: > On 10/11/2019 8:29 AM, Frederic Parain wrote: >> >>> On Oct 10, 2019, at 21:15, David Holmes wrote: >>>>> --- >>>>> >>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>> >>>>> I do not like this new method: >>>>> >>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>> +? assert(is_java_type(t), "%d", (int)t); >>>>> +? return (is_reference_type(t) ? T_OBJECT : t); >>>>> +} >>>>> >>>>> I found it's use in the code was far less clear than the original >>>>> code. I like to explicitly see where arrays and objects are being >>>>> treated the same (or differently). >>>> This is in line with the change that I recently completed for >>>> JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY >>>> with call to is_reference_type.? Please refer to John's response to >>>> Coleen's review comment that I believe addresses your concern as >>>> well. >>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>>> >>> I can't say that I agree. A simple query like is_reference_type() is >>> perfectly fine. But reducing all reference types to just T_OBJECT is >>> something that, to me, needs to be consciously chosen when a new >>> reference type is added. This approach could hide bugs as it will be >>> easy to miss locations that might new to handle the new reference >>> type differently. Just my 2c. >> I agree with David here. >> ? 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to >> T_OBJECT can be a source >> ????? of confusion because each time we see T_OBJECT in the source >> code, we don?t know if it >> ????? means T_OBJECT only or all reference types. >> ? 2 - the name of the method ?primitive_or_object()? is confusing too, >> its meaning is not obvious >> ????? and it doesn?t sound like a conversion method (which it is) >> >> Would it be possible to have an internal T_REFERENCE type to clearly >> indicate erased reference types? >> The use of a T_REFERENCE case in a switch statement would clearly >> indicate that the case applies >> to all reference types. >> Then the method could be renamed: as_primitive_or_REFERENCE() which I >> believe makes the conversion >> more explicit. >> >> My 2c. > > Thank you Fred for reviewing this change and your 2c!? Given both you > and David make valid points, it seems obvious more discussion is > warranted concerning specifically primitive_or_object().? So, I have > removed that from this change and have posted a new webrev at: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ > > The change is now just limited to changing the hard coded literals to > JVM_SIGNATURE_*. > > Thanks, > Lois > >> >> Fred >> >> >> >> > From david.holmes at oracle.com Fri Oct 11 23:18:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Oct 2019 09:18:23 +1000 Subject: RFR: 8232107: support ThreadPriorityPolicy flag on AIX In-Reply-To: References: Message-ID: On 12/10/2019 12:20 am, Baesken, Matthias wrote: > Hello, please review the following small change . > It adds support for the ThreadPriorityPolicy flag on AIX (and brings the implementation in os_aix closer to what we have in os_linux ). In that sense this is reviewed. But ... > While ThreadPriorityPolicy is an "old" flag, we have some customers using it so it would be nice to support it on all UNIX platforms . "support" is a strong word. It's affects are well defined in the sense of what the policy will change, but it is completely untested and anything that messes with priority could easily induce problems inside the VM. Caveat Emptor. To me this is a candidate for removal, not extended adoption. Cheers, David ----- > > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8232107 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232107.0/ > > > Best regards, Matthias > From stefan.reich.maker.of.eye at googlemail.com Sun Oct 13 15:04:30 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sun, 13 Oct 2019 17:04:30 +0200 Subject: Compiler threads Message-ID: Just a quick question: How many compiler threads does HotSpot use? Does it depend on then number of Java threads running? For example: Let's say I want the fastest startup time possible for a single-thread application, so I want parallel JIT compilation on, say, 7, out of 8 cores. Is that possible? Many greetings, Stefan -- Stefan Reich BotCompany.de // Java-based operating systems From volker.simonis at gmail.com Sun Oct 13 17:48:40 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 13 Oct 2019 19:48:40 +0200 Subject: Compiler threads In-Reply-To: References: Message-ID: Hi Stefan, the answer to your questions depends a little bit on the Java version you are using. In jdk8 you can use -XX:CICompilerCount= to explicitly set the number of compiler threads and "-XX:+CICompilerCountPerCPU" to automatically set the number of compiler threads to "1 compiler thread for log(N CPUs)". If you use tiered compilation, which is the default, the "AdvancedThresholdPolicy" compilation policy will be used (can be controlled with "-XX:CompilationPolicyChoice="), which automatically enables "CICompilerCountPerCPU" but sets the number of compiler threads to log(N CPUs) * log(log(N CPUs)). In general, the number of compiler threads when using tiered compilation is distributed such that 1/3 of the total compiler threads will be tier 1 (i.e. C1) compiler threads and 2/3 will be tier 2 (i.e. C2) compiler threads. With jdk11 this system has been reworked and made more dynamic by introducing the option "-XX:+UseDynamicNumberOfCompilerThreads" which is active by default. It will automatically spawn new compiler threads, if the compilation queues get full (see https://bugs.openjdk.java.net/browse/JDK-8198756 and https://bugs.openjdk.java.net/browse/JDK-8201235 for a more detailed explanation of the parameter). Best regards, Volker On Sun, Oct 13, 2019 at 5:06 PM Stefan Reich wrote: > > Just a quick question: How many compiler threads does HotSpot use? Does it > depend on then number of Java threads running? > > For example: Let's say I want the fastest startup time possible for a > single-thread application, so I want parallel JIT compilation on, say, 7, > out of 8 cores. Is that possible? > > Many greetings, > Stefan > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Sun Oct 13 17:51:35 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sun, 13 Oct 2019 19:51:35 +0200 Subject: Compiler threads In-Reply-To: References: Message-ID: Hi Volker, OK, so it seems the answer is basically "It's complicated, but we have spent a lot of thought on sensible defaults"... :-) log(N CPUs) * log(log(N CPUs) << that's pretty amazing though Thanks, Stefan On Sun, 13 Oct 2019 at 19:48, Volker Simonis wrote: > Hi Stefan, > > the answer to your questions depends a little bit on the Java version > you are using. > > In jdk8 you can use -XX:CICompilerCount= to explicitly set the > number of compiler threads and "-XX:+CICompilerCountPerCPU" to > automatically set the number of compiler threads to "1 compiler thread > for log(N CPUs)". If you use tiered compilation, which is the default, > the "AdvancedThresholdPolicy" compilation policy will be used (can be > controlled with "-XX:CompilationPolicyChoice="), which > automatically enables "CICompilerCountPerCPU" but sets the number of > compiler threads to log(N CPUs) * log(log(N CPUs)). > > In general, the number of compiler threads when using tiered > compilation is distributed such that 1/3 of the total compiler threads > will be tier 1 (i.e. C1) compiler threads and 2/3 will be tier 2 (i.e. > C2) compiler threads. > > With jdk11 this system has been reworked and made more dynamic by > introducing the option "-XX:+UseDynamicNumberOfCompilerThreads" which > is active by default. It will automatically spawn new compiler > threads, if the compilation queues get full (see > https://bugs.openjdk.java.net/browse/JDK-8198756 and > https://bugs.openjdk.java.net/browse/JDK-8201235 for a more detailed > explanation of the parameter). > > Best regards, > Volker > > On Sun, Oct 13, 2019 at 5:06 PM Stefan Reich > wrote: > > > > Just a quick question: How many compiler threads does HotSpot use? Does > it > > depend on then number of Java threads running? > > > > For example: Let's say I want the fastest startup time possible for a > > single-thread application, so I want parallel JIT compilation on, say, 7, > > out of 8 cores. Is that possible? > > > > Many greetings, > > Stefan > > > > -- > > Stefan Reich > > BotCompany.de // Java-based operating systems > -- Stefan Reich BotCompany.de // Java-based operating systems From christoph.langer at sap.com Mon Oct 14 07:05:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Oct 2019 07:05:31 +0000 Subject: RFR: 8232107: support ThreadPriorityPolicy flag on AIX In-Reply-To: References: Message-ID: Hi Matthias, David, first of all, +1 from my side. I think it's beneficial to make AIX behave most similar to Linux at this place. Whether the whole feature should be terminally deprecated and removed is a different discussion. Just my 5cents ?? Cheers Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > David Holmes > Sent: Samstag, 12. Oktober 2019 01:18 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR: 8232107: support ThreadPriorityPolicy flag on AIX > > On 12/10/2019 12:20 am, Baesken, Matthias wrote: > > Hello, please review the following small change . > > It adds support for the ThreadPriorityPolicy flag on AIX (and brings the > implementation in os_aix closer to what we have in os_linux ). > > In that sense this is reviewed. But ... > > > While ThreadPriorityPolicy is an "old" flag, we have some customers > using it so it would be nice to support it on all UNIX platforms . > > "support" is a strong word. It's affects are well defined in the sense > of what the policy will change, but it is completely untested and > anything that messes with priority could easily induce problems inside > the VM. Caveat Emptor. > > To me this is a candidate for removal, not extended adoption. > > Cheers, > David > ----- > > > > > Bug / webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8232107 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8232107.0/ > > > > > > Best regards, Matthias > > From matthias.baesken at sap.com Mon Oct 14 07:48:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 14 Oct 2019 07:48:05 +0000 Subject: RFR: 8232107: support ThreadPriorityPolicy flag on AIX In-Reply-To: References: Message-ID: Hi Christoph/David, thanks for the reviews ! Best regards, Matthias > Hi Matthias, David, > > first of all, +1 from my side. > > I think it's beneficial to make AIX behave most similar to Linux at this place. > Whether the whole feature should be terminally deprecated and removed is > a different discussion. Just my 5cents ?? > > Cheers > Christoph > From martin.doerr at sap.com Mon Oct 14 13:36:28 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Oct 2019 13:36:28 +0000 Subject: [DMARC FAILURE] Re: Compiler threads In-Reply-To: References: Message-ID: Hi Stefan, > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though This formula is from a time before UseDynamicNumberOfCompilerThreads was introduced. I guess people usually don't want to spend all their hardware threads for JIT compilation, but it may be beneficial to use a higher value depending on your scenario. With UseDynamicNumberOfCompilerThreads, CICompilerCount sets the upper limit. The JVM will dynamically add and remove threads between 1 per type and 1/3 for C1 2/3 for C2 of this value in total. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Stefan Reich > Sent: Sonntag, 13. Oktober 2019 19:52 > To: Volker Simonis > Cc: hotspot-dev Source Developers > Subject: [DMARC FAILURE] Re: Compiler threads > > Hi Volker, > > OK, so it seems the answer is basically "It's complicated, but we have > spent a lot of thought on sensible defaults"... :-) > > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though > > Thanks, > Stefan > > On Sun, 13 Oct 2019 at 19:48, Volker Simonis > wrote: > > > Hi Stefan, > > > > the answer to your questions depends a little bit on the Java version > > you are using. > > > > In jdk8 you can use -XX:CICompilerCount= to explicitly set the > > number of compiler threads and "-XX:+CICompilerCountPerCPU" to > > automatically set the number of compiler threads to "1 compiler thread > > for log(N CPUs)". If you use tiered compilation, which is the default, > > the "AdvancedThresholdPolicy" compilation policy will be used (can be > > controlled with "-XX:CompilationPolicyChoice="), which > > automatically enables "CICompilerCountPerCPU" but sets the number of > > compiler threads to log(N CPUs) * log(log(N CPUs)). > > > > In general, the number of compiler threads when using tiered > > compilation is distributed such that 1/3 of the total compiler threads > > will be tier 1 (i.e. C1) compiler threads and 2/3 will be tier 2 (i.e. > > C2) compiler threads. > > > > With jdk11 this system has been reworked and made more dynamic by > > introducing the option "-XX:+UseDynamicNumberOfCompilerThreads" > which > > is active by default. It will automatically spawn new compiler > > threads, if the compilation queues get full (see > > https://bugs.openjdk.java.net/browse/JDK-8198756 and > > https://bugs.openjdk.java.net/browse/JDK-8201235 for a more detailed > > explanation of the parameter). > > > > Best regards, > > Volker > > > > On Sun, Oct 13, 2019 at 5:06 PM Stefan Reich > > wrote: > > > > > > Just a quick question: How many compiler threads does HotSpot use? > Does > > it > > > depend on then number of Java threads running? > > > > > > For example: Let's say I want the fastest startup time possible for a > > > single-thread application, so I want parallel JIT compilation on, say, 7, > > > out of 8 cores. Is that possible? > > > > > > Many greetings, > > > Stefan > > > > > > -- > > > Stefan Reich > > > BotCompany.de // Java-based operating systems > > > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Mon Oct 14 14:53:33 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 14 Oct 2019 16:53:33 +0200 Subject: [DMARC FAILURE] Re: Compiler threads In-Reply-To: References: Message-ID: Yeah i think I see the point. Is it calculated without a constant factor? Just round up the result? On Mon, Oct 14, 2019, 15:36 Doerr, Martin wrote: > Hi Stefan, > > > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though > This formula is from a time before UseDynamicNumberOfCompilerThreads was > introduced. > I guess people usually don't want to spend all their hardware threads for > JIT compilation, > but it may be beneficial to use a higher value depending on your scenario. > With UseDynamicNumberOfCompilerThreads, CICompilerCount sets the upper > limit. The JVM will dynamically add and remove threads between 1 per type > and 1/3 for C1 2/3 for C2 of this value in total. > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Stefan Reich > > Sent: Sonntag, 13. Oktober 2019 19:52 > > To: Volker Simonis > > Cc: hotspot-dev Source Developers > > Subject: [DMARC FAILURE] Re: Compiler threads > > > > Hi Volker, > > > > OK, so it seems the answer is basically "It's complicated, but we have > > spent a lot of thought on sensible defaults"... :-) > > > > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though > > > > Thanks, > > Stefan > > > > On Sun, 13 Oct 2019 at 19:48, Volker Simonis > > wrote: > > > > > Hi Stefan, > > > > > > the answer to your questions depends a little bit on the Java version > > > you are using. > > > > > > In jdk8 you can use -XX:CICompilerCount= to explicitly set the > > > number of compiler threads and "-XX:+CICompilerCountPerCPU" to > > > automatically set the number of compiler threads to "1 compiler thread > > > for log(N CPUs)". If you use tiered compilation, which is the default, > > > the "AdvancedThresholdPolicy" compilation policy will be used (can be > > > controlled with "-XX:CompilationPolicyChoice="), which > > > automatically enables "CICompilerCountPerCPU" but sets the number of > > > compiler threads to log(N CPUs) * log(log(N CPUs)). > > > > > > In general, the number of compiler threads when using tiered > > > compilation is distributed such that 1/3 of the total compiler threads > > > will be tier 1 (i.e. C1) compiler threads and 2/3 will be tier 2 (i.e. > > > C2) compiler threads. > > > > > > With jdk11 this system has been reworked and made more dynamic by > > > introducing the option "-XX:+UseDynamicNumberOfCompilerThreads" > > which > > > is active by default. It will automatically spawn new compiler > > > threads, if the compilation queues get full (see > > > https://bugs.openjdk.java.net/browse/JDK-8198756 and > > > https://bugs.openjdk.java.net/browse/JDK-8201235 for a more detailed > > > explanation of the parameter). > > > > > > Best regards, > > > Volker > > > > > > On Sun, Oct 13, 2019 at 5:06 PM Stefan Reich > > > wrote: > > > > > > > > Just a quick question: How many compiler threads does HotSpot use? > > Does > > > it > > > > depend on then number of Java threads running? > > > > > > > > For example: Let's say I want the fastest startup time possible for a > > > > single-thread application, so I want parallel JIT compilation on, > say, 7, > > > > out of 8 cores. Is that possible? > > > > > > > > Many greetings, > > > > Stefan > > > > > > > > -- > > > > Stefan Reich > > > > BotCompany.de // Java-based operating systems > > > > > > > > > -- > > Stefan Reich > > BotCompany.de // Java-based operating systems > From martin.doerr at sap.com Mon Oct 14 15:06:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Oct 2019 15:06:51 +0000 Subject: [DMARC FAILURE] Re: Compiler threads In-Reply-To: References: Message-ID: By specifying CICompilerCount you?ll get the following upper limits for C1 and C2: int count = CICompilerCount; set_c1_count(MAX2(count / 3, 1)); set_c2_count(MAX2(count - c1_count(), 1)); With CICompilerCount = 7: Up to 2 C1, 5 C2 threads. From: Stefan Reich Sent: Montag, 14. Oktober 2019 16:54 To: Doerr, Martin Cc: volker.simonis at gmail.com; hotspot-dev Source Developers Subject: Re: [DMARC FAILURE] Re: Compiler threads Yeah i think I see the point. Is it calculated without a constant factor? Just round up the result? On Mon, Oct 14, 2019, 15:36 Doerr, Martin > wrote: Hi Stefan, > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though This formula is from a time before UseDynamicNumberOfCompilerThreads was introduced. I guess people usually don't want to spend all their hardware threads for JIT compilation, but it may be beneficial to use a higher value depending on your scenario. With UseDynamicNumberOfCompilerThreads, CICompilerCount sets the upper limit. The JVM will dynamically add and remove threads between 1 per type and 1/3 for C1 2/3 for C2 of this value in total. Best regards, Martin > -----Original Message----- > From: hotspot-dev > On Behalf Of > Stefan Reich > Sent: Sonntag, 13. Oktober 2019 19:52 > To: Volker Simonis > > Cc: hotspot-dev Source Developers > > Subject: [DMARC FAILURE] Re: Compiler threads > > Hi Volker, > > OK, so it seems the answer is basically "It's complicated, but we have > spent a lot of thought on sensible defaults"... :-) > > log(N CPUs) * log(log(N CPUs) << that's pretty amazing though > > Thanks, > Stefan > > On Sun, 13 Oct 2019 at 19:48, Volker Simonis > > wrote: > > > Hi Stefan, > > > > the answer to your questions depends a little bit on the Java version > > you are using. > > > > In jdk8 you can use -XX:CICompilerCount= to explicitly set the > > number of compiler threads and "-XX:+CICompilerCountPerCPU" to > > automatically set the number of compiler threads to "1 compiler thread > > for log(N CPUs)". If you use tiered compilation, which is the default, > > the "AdvancedThresholdPolicy" compilation policy will be used (can be > > controlled with "-XX:CompilationPolicyChoice="), which > > automatically enables "CICompilerCountPerCPU" but sets the number of > > compiler threads to log(N CPUs) * log(log(N CPUs)). > > > > In general, the number of compiler threads when using tiered > > compilation is distributed such that 1/3 of the total compiler threads > > will be tier 1 (i.e. C1) compiler threads and 2/3 will be tier 2 (i.e. > > C2) compiler threads. > > > > With jdk11 this system has been reworked and made more dynamic by > > introducing the option "-XX:+UseDynamicNumberOfCompilerThreads" > which > > is active by default. It will automatically spawn new compiler > > threads, if the compilation queues get full (see > > https://bugs.openjdk.java.net/browse/JDK-8198756 and > > https://bugs.openjdk.java.net/browse/JDK-8201235 for a more detailed > > explanation of the parameter). > > > > Best regards, > > Volker > > > > On Sun, Oct 13, 2019 at 5:06 PM Stefan Reich > > > wrote: > > > > > > Just a quick question: How many compiler threads does HotSpot use? > Does > > it > > > depend on then number of Java threads running? > > > > > > For example: Let's say I want the fastest startup time possible for a > > > single-thread application, so I want parallel JIT compilation on, say, 7, > > > out of 8 cores. Is that possible? > > > > > > Many greetings, > > > Stefan > > > > > > -- > > > Stefan Reich > > > BotCompany.de // Java-based operating systems > > > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From frederic.parain at oracle.com Mon Oct 14 15:35:52 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Oct 2019 11:35:52 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> Message-ID: <689963DE-A624-4E2C-9E31-CA634BE5A6B7@oracle.com> Looks good to me. Thank you! Fred > On Oct 11, 2019, at 15:32, Lois Foltan wrote: > > On 10/11/2019 8:29 AM, Frederic Parain wrote: >> >>> On Oct 10, 2019, at 21:15, David Holmes wrote: >>>>> --- >>>>> >>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>> >>>>> I do not like this new method: >>>>> >>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>> + assert(is_java_type(t), "%d", (int)t); >>>>> + return (is_reference_type(t) ? T_OBJECT : t); >>>>> +} >>>>> >>>>> I found it's use in the code was far less clear than the original code. I like to explicitly see where arrays and objects are being treated the same (or differently). >>>> This is in line with the change that I recently completed for JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type. Please refer to John's response to Coleen's review comment that I believe addresses your concern as well. https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>> I can't say that I agree. A simple query like is_reference_type() is perfectly fine. But reducing all reference types to just T_OBJECT is something that, to me, needs to be consciously chosen when a new reference type is added. This approach could hide bugs as it will be easy to miss locations that might new to handle the new reference type differently. Just my 2c. >> I agree with David here. >> 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to T_OBJECT can be a source >> of confusion because each time we see T_OBJECT in the source code, we don?t know if it >> means T_OBJECT only or all reference types. >> 2 - the name of the method ?primitive_or_object()? is confusing too, its meaning is not obvious >> and it doesn?t sound like a conversion method (which it is) >> >> Would it be possible to have an internal T_REFERENCE type to clearly indicate erased reference types? >> The use of a T_REFERENCE case in a switch statement would clearly indicate that the case applies >> to all reference types. >> Then the method could be renamed: as_primitive_or_REFERENCE() which I believe makes the conversion >> more explicit. >> >> My 2c. > > Thank you Fred for reviewing this change and your 2c! Given both you and David make valid points, it seems obvious more discussion is warranted concerning specifically primitive_or_object(). So, I have removed that from this change and have posted a new webrev at: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ > > The change is now just limited to changing the hard coded literals to JVM_SIGNATURE_*. > > Thanks, > Lois > >> >> Fred >> >> >> >> > From sgehwolf at redhat.com Tue Oct 15 09:19:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Oct 2019 11:19:50 +0200 Subject: RFR: 8230305: Cgroups v2: Container awareness Message-ID: <072f66ee8c44034831b4e38f6470da4bff6edd07.camel@redhat.com> Hi, Please review this update to the container detection code which adds cgroup version 2 support. Initial review of this started in [1]. Bob preferred one big patch and didn't like the other refactoring in os_linux so this has been dropped. This new patch includes both, the refactoring to move cgroup v1 specific implementation out of osContainer_linux.{h,c}pp files[2] as well as updated detection code and the implementation for cgroups v2[3]. After this patch, osContainer_linux{h,c}pp files are cgroups version agnostic. Implementations for specific versions are in cgroupV{1,2}Subsystem.{c,h}pp files. Some shared, cgroup version agnostic code is in cgroupSubsystem.{c,h}pp. Updated detection logic looks in /proc/cgroups first for hierarchy ids of cpu/cpuset/cpuacct/memory controllers. If the hierarchy id for all of them is 0 and they're all enabled, cgroups v2, unified hierarchy is assumed. Otherwise it uses cgroups v1 controllers (also known as hybrid or legacy hierarchy). Note that controllers can be only be mounted via one or the other hierarchy, legacy (v1) or unified (v2) - exclusive[4]. Note that for the cgroups v2 cpu_shares() implementation a reverse mapping is needed for the plain value exposed via cpu.weight. Additionally, there doesn't seem to be an API exposed to use for an implementation of memory_max_usage_in_bytes() in cgroups v2. Hence, it returns OSCONTAINER_ERROR which is mapped to "not supported" elsewhere in hotspot code. Once reviewed, I intend to push this in two changesets/bugs. One for the refactoring work (no-op) as JDK-8230848. Another for the cgroupv2 impl with JDK-8230305. Bug: https://bugs.openjdk.java.net/browse/JDK-8230305 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/cgroupsv2-hotspot/02/webrev/ Testing: tier1 tests on Linux x86_64. Docker/podman hotspot tests on F30 with hybrid cgroup v1 hierarchy. Hotspot container tests on F31 with unified hierarchy on Linux x86_64. jdk/submit. All pass. Thoughts? Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039605.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039708.html [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/04/webrev/ [3] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/06/webrev/ [4] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#mounting "All controllers which support v2 and are not bound to a v1 hierarchy are automatically bound to the v2 hierarchy and show up at the root. Controllers which are not in active use in the v2 hierarchy can be bound to other hierarchies." From adinn at redhat.com Tue Oct 15 14:52:46 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 15 Oct 2019 15:52:46 +0100 Subject: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: <6a1385ba-ab76-c6e6-df7c-ad6f0f6baa1e@redhat.com> References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com> <6a1385ba-ab76-c6e6-df7c-ad6f0f6baa1e@redhat.com> Message-ID: <4edf7fe7-edfe-33b0-b1ae-cca61e02438c@redhat.com> Hi Zhengyu, On 04/10/2019 20:22, Zhengyu Gu wrote: > Ping! May I get a second review? Yes, the patch looks good. Only one tentative suggestion. It might help those coming to this from the x86_64 code to add a comment before the calls to gen_pin_object and gen_unpin_object to mention that those calls handle saving and restoring of any registers clobbered by the call i.e. 1986 if (Universe::heap()->supports_object_pinning()) { + // gen_pin_object handles save and restore + // of any clobbered registers 1987 gen_pin_object(masm, thread, in_arg); and 2209 } + // gen_pin_object handles save and restore + // of any other clobbered registers 2210 gen_unpin_object(masm, thread, in_regs[i]); (note 'other' in the 2nd comment means other than the result register) You decide. I don't need another webrev. regards, Andrew Dinn ----------- > On 9/18/19 10:46 AM, Roman Kennke wrote: >> Hi Zhengyu, >> >> It looks good to me! >> >> Thanks, >> Roman >> >> >>> Please review this patch that supports JNI critical functions in >>> object pinning capable GCs on x86_32 platforms. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ >>> >>> Test: >>> ?? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on >>> Linux x86_64. >>> ?? hotspot_gc, hotspot_runtime and hotspot_compiler >>> ?? Submit tests in progress. >>> >>> Thanks, >>> >>> -Zhengyu > From zgu at redhat.com Tue Oct 15 15:04:14 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 15 Oct 2019 11:04:14 -0400 Subject: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: <4edf7fe7-edfe-33b0-b1ae-cca61e02438c@redhat.com> References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com> <6a1385ba-ab76-c6e6-df7c-ad6f0f6baa1e@redhat.com> <4edf7fe7-edfe-33b0-b1ae-cca61e02438c@redhat.com> Message-ID: <4db7d043-7325-00e9-b3d0-a4ac314d0cfd@redhat.com> Thanks, Andrew. I will add comments as you suggested before push. -Zhengyu On 10/15/19 10:52 AM, Andrew Dinn wrote: > Hi Zhengyu, > > On 04/10/2019 20:22, Zhengyu Gu wrote: >> Ping! May I get a second review? > > Yes, the patch looks good. > > Only one tentative suggestion. It might help those coming to this from > the x86_64 code to add a comment before the calls to gen_pin_object and > gen_unpin_object to mention that those calls handle saving and restoring > of any registers clobbered by the call i.e. > > 1986 if (Universe::heap()->supports_object_pinning()) { > + // gen_pin_object handles save and restore > + // of any clobbered registers > 1987 gen_pin_object(masm, thread, in_arg); > > and > > > 2209 } > + // gen_pin_object handles save and restore > + // of any other clobbered registers > 2210 gen_unpin_object(masm, thread, in_regs[i]); > > (note 'other' in the 2nd comment means other than the result register) > > You decide. I don't need another webrev. > > regards, > > > Andrew Dinn > ----------- > >> On 9/18/19 10:46 AM, Roman Kennke wrote: >>> Hi Zhengyu, >>> >>> It looks good to me! >>> >>> Thanks, >>> Roman >>> >>> >>>> Please review this patch that supports JNI critical functions in >>>> object pinning capable GCs on x86_32 platforms. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ >>>> >>>> Test: >>>> ?? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on >>>> Linux x86_64. >>>> ?? hotspot_gc, hotspot_runtime and hotspot_compiler >>>> ?? Submit tests in progress. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >> From lois.foltan at oracle.com Tue Oct 15 17:45:02 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 15 Oct 2019 13:45:02 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> Message-ID: <14372ce9-f1a4-f255-1d12-54e55d94d8f9@oracle.com> Thanks again David for the review! Lois On 10/11/2019 7:04 PM, David Holmes wrote: > Thanks Lois LGTM. > > David > > On 12/10/2019 5:32 am, Lois Foltan wrote: >> On 10/11/2019 8:29 AM, Frederic Parain wrote: >>> >>>> On Oct 10, 2019, at 21:15, David Holmes >>>> wrote: >>>>>> --- >>>>>> >>>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>>> >>>>>> I do not like this new method: >>>>>> >>>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>>> +? assert(is_java_type(t), "%d", (int)t); >>>>>> +? return (is_reference_type(t) ? T_OBJECT : t); >>>>>> +} >>>>>> >>>>>> I found it's use in the code was far less clear than the original >>>>>> code. I like to explicitly see where arrays and objects are being >>>>>> treated the same (or differently). >>>>> This is in line with the change that I recently completed for >>>>> JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY >>>>> with call to is_reference_type.? Please refer to John's response >>>>> to Coleen's review comment that I believe addresses your concern >>>>> as well. >>>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>>>> >>>> I can't say that I agree. A simple query like is_reference_type() >>>> is perfectly fine. But reducing all reference types to just >>>> T_OBJECT is something that, to me, needs to be consciously chosen >>>> when a new reference type is added. This approach could hide bugs >>>> as it will be easy to miss locations that might new to handle the >>>> new reference type differently. Just my 2c. >>> I agree with David here. >>> ? 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) >>> to T_OBJECT can be a source >>> ????? of confusion because each time we see T_OBJECT in the source >>> code, we don?t know if it >>> ????? means T_OBJECT only or all reference types. >>> ? 2 - the name of the method ?primitive_or_object()? is confusing >>> too, its meaning is not obvious >>> ????? and it doesn?t sound like a conversion method (which it is) >>> >>> Would it be possible to have an internal T_REFERENCE type to clearly >>> indicate erased reference types? >>> The use of a T_REFERENCE case in a switch statement would clearly >>> indicate that the case applies >>> to all reference types. >>> Then the method could be renamed: as_primitive_or_REFERENCE() which >>> I believe makes the conversion >>> more explicit. >>> >>> My 2c. >> >> Thank you Fred for reviewing this change and your 2c!? Given both you >> and David make valid points, it seems obvious more discussion is >> warranted concerning specifically primitive_or_object().? So, I have >> removed that from this change and have posted a new webrev at: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ >> >> The change is now just limited to changing the hard coded literals to >> JVM_SIGNATURE_*. >> >> Thanks, >> Lois >> >>> >>> Fred >>> >>> >>> >>> >> From lois.foltan at oracle.com Tue Oct 15 17:45:18 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 15 Oct 2019 13:45:18 -0400 Subject: RFR (L) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently In-Reply-To: <689963DE-A624-4E2C-9E31-CA634BE5A6B7@oracle.com> References: <9d2ee35e-8650-2d3c-03be-126b9dd940b7@oracle.com> <256638a2-c4f2-57d9-f790-0c682ab59027@oracle.com> <9d312872-fa6a-7c3e-7d9b-35a889019d49@oracle.com> <2B4E195C-D9C4-4839-A4A5-CCE897824F6C@oracle.com> <136675d6-94bb-ab6d-956e-55f7ebff4d88@oracle.com> <689963DE-A624-4E2C-9E31-CA634BE5A6B7@oracle.com> Message-ID: <7ae38e0f-e556-9260-b02c-207d573bb4f6@oracle.com> Thanks Fred! Lois On 10/14/2019 11:35 AM, Frederic Parain wrote: > Looks good to me. > Thank you! > > Fred > > >> On Oct 11, 2019, at 15:32, Lois Foltan wrote: >> >> On 10/11/2019 8:29 AM, Frederic Parain wrote: >>>> On Oct 10, 2019, at 21:15, David Holmes wrote: >>>>>> --- >>>>>> >>>>>> src/hotspot/share/utilities/globalDefinitions.hpp >>>>>> >>>>>> I do not like this new method: >>>>>> >>>>>> +inline BasicType primitive_or_object(BasicType t) { >>>>>> + assert(is_java_type(t), "%d", (int)t); >>>>>> + return (is_reference_type(t) ? T_OBJECT : t); >>>>>> +} >>>>>> >>>>>> I found it's use in the code was far less clear than the original code. I like to explicitly see where arrays and objects are being treated the same (or differently). >>>>> This is in line with the change that I recently completed for JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type. Please refer to John's response to Coleen's review comment that I believe addresses your concern as well. https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039486.html >>>> I can't say that I agree. A simple query like is_reference_type() is perfectly fine. But reducing all reference types to just T_OBJECT is something that, to me, needs to be consciously chosen when a new reference type is added. This approach could hide bugs as it will be easy to miss locations that might new to handle the new reference type differently. Just my 2c. >>> I agree with David here. >>> 1 - erasing all reference types (T_OBJECT, T_ARRAY, T_VALUETYPE) to T_OBJECT can be a source >>> of confusion because each time we see T_OBJECT in the source code, we don?t know if it >>> means T_OBJECT only or all reference types. >>> 2 - the name of the method ?primitive_or_object()? is confusing too, its meaning is not obvious >>> and it doesn?t sound like a conversion method (which it is) >>> >>> Would it be possible to have an internal T_REFERENCE type to clearly indicate erased reference types? >>> The use of a T_REFERENCE case in a switch statement would clearly indicate that the case applies >>> to all reference types. >>> Then the method could be renamed: as_primitive_or_REFERENCE() which I believe makes the conversion >>> more explicit. >>> >>> My 2c. >> Thank you Fred for reviewing this change and your 2c! Given both you and David make valid points, it seems obvious more discussion is warranted concerning specifically primitive_or_object(). So, I have removed that from this change and have posted a new webrev at: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8231844.2/webrev/ >> >> The change is now just limited to changing the hard coded literals to JVM_SIGNATURE_*. >> >> Thanks, >> Lois >> >>> Fred >>> >>> >>> >>> From coleen.phillimore at oracle.com Wed Oct 16 13:48:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Oct 2019 09:48:24 -0400 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading Message-ID: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> Summary: call the MDO destructor during class unloading. Also moved the other C heap deallocation from method_data to release_C_heap_structures.? Methods won't have method_data unless they're deallocated from the InstanceKlass.? The other paths to deallocate_contents are before the method is called. Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8232112 Thanks, Coleen From david.holmes at oracle.com Thu Oct 17 00:25:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 10:25:35 +1000 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading In-Reply-To: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> References: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> Message-ID: <7a594e1a-34ec-960a-0629-99e1767eb465@oracle.com> Hi Coleen, On 16/10/2019 11:48 pm, coleen.phillimore at oracle.com wrote: > Summary: call the MDO destructor during class unloading. > > Also moved the other C heap deallocation from method_data to > release_C_heap_structures.? Methods won't have method_data unless > they're deallocated from the InstanceKlass.? The other paths to > deallocate_contents are before the method is called. I'm not understanding why delete is not used to run the destructor and free the memory. Is this memory that is being specially managed? Thanks, David > Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8232112 > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Oct 17 02:18:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Oct 2019 22:18:02 -0400 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading In-Reply-To: <7a594e1a-34ec-960a-0629-99e1767eb465@oracle.com> References: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> <7a594e1a-34ec-960a-0629-99e1767eb465@oracle.com> Message-ID: <8fed9713-147f-0848-5634-f38e2ad39f2d@oracle.com> On 10/16/19 8:25 PM, David Holmes wrote: > Hi Coleen, > > On 16/10/2019 11:48 pm, coleen.phillimore at oracle.com wrote: >> Summary: call the MDO destructor during class unloading. >> >> Also moved the other C heap deallocation from method_data to >> release_C_heap_structures.? Methods won't have method_data unless >> they're deallocated from the InstanceKlass.? The other paths to >> deallocate_contents are before the method is called. > > I'm not understanding why delete is not used to run the destructor and > free the memory. Is this memory that is being specially managed? The _extra_data_lock Mutex is embedded in the MethodData, and MethodData is allocated in Metaspace which is deleted en-masse when a class is unloaded.? It also may be deleted during redefinition, when the InstanceKlass is deleted (all old methods are not running). I actually tested a version where I changed _extra_data_lock to a Mutex* and used new/delete for it.? This caused a slight degredation in one of our performance benchmarks, so I changed it to call the destructor explicitly (with Kim's help with syntax). Thanks, Coleen > > Thanks, > David > >> Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8232112 >> >> Thanks, >> Coleen >> >> From david.holmes at oracle.com Thu Oct 17 03:51:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 13:51:30 +1000 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading In-Reply-To: <8fed9713-147f-0848-5634-f38e2ad39f2d@oracle.com> References: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> <7a594e1a-34ec-960a-0629-99e1767eb465@oracle.com> <8fed9713-147f-0848-5634-f38e2ad39f2d@oracle.com> Message-ID: On 17/10/2019 12:18 pm, coleen.phillimore at oracle.com wrote: > On 10/16/19 8:25 PM, David Holmes wrote: >> Hi Coleen, >> >> On 16/10/2019 11:48 pm, coleen.phillimore at oracle.com wrote: >>> Summary: call the MDO destructor during class unloading. >>> >>> Also moved the other C heap deallocation from method_data to >>> release_C_heap_structures.? Methods won't have method_data unless >>> they're deallocated from the InstanceKlass.? The other paths to >>> deallocate_contents are before the method is called. >> >> I'm not understanding why delete is not used to run the destructor and >> free the memory. Is this memory that is being specially managed? > > The _extra_data_lock Mutex is embedded in the MethodData, and MethodData > is allocated in Metaspace which is deleted en-masse when a class is > unloaded.? It also may be deleted during redefinition, when the > InstanceKlass is deleted (all old methods are not running). Okay - thanks for clarifying. The change seems fine to me. Thanks, David ----- > I actually tested a version where I changed _extra_data_lock to a Mutex* > and used new/delete for it.? This caused a slight degredation in one of > our performance benchmarks, so I changed it to call the destructor > explicitly (with Kim's help with syntax). > > Thanks, > Coleen >> >> Thanks, >> David >> >>> Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8232112 >>> >>> Thanks, >>> Coleen >>> >>> > From erik.osterlund at oracle.com Thu Oct 17 11:31:23 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 17 Oct 2019 13:31:23 +0200 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading In-Reply-To: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> References: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> Message-ID: Hi Coleen Looks good. Thanks for fixing! /Erik On 2019-10-16 15:48, coleen.phillimore at oracle.com wrote: > Summary: call the MDO destructor during class unloading. > > Also moved the other C heap deallocation from method_data to > release_C_heap_structures.? Methods won't have method_data unless > they're deallocated from the InstanceKlass.? The other paths to > deallocate_contents are before the method is called. > > Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8232112 > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Oct 17 11:34:06 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Oct 2019 07:34:06 -0400 Subject: RFR (S) 8232112: MDO extra_data_lock leaks during class unloading In-Reply-To: References: <0aa7c554-cb14-be53-517e-f9f890a50336@oracle.com> Message-ID: <1c18cd09-e4d3-862b-3f4f-9b22521a7ec8@oracle.com> Thank you, David and Erik, for the reviews, and for Erik for noticing this bug! Coleen On 10/17/19 7:31 AM, Erik ?sterlund wrote: > Hi Coleen > > Looks good. Thanks for fixing! > > /Erik > > On 2019-10-16 15:48, coleen.phillimore at oracle.com wrote: >> Summary: call the MDO destructor during class unloading. >> >> Also moved the other C heap deallocation from method_data to >> release_C_heap_structures.? Methods won't have method_data unless >> they're deallocated from the InstanceKlass.? The other paths to >> deallocate_contents are before the method is called. >> >> Tested with tier1 all Oracle platforms, and tier2-6 on linux-x64. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8232112.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8232112 >> >> Thanks, >> Coleen >> >> From leo.korinth at oracle.com Fri Oct 18 08:20:04 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 18 Oct 2019 10:20:04 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector Message-ID: Hi, Here is a patch that removes the CMS GC. I have neither tested arm nor ppc; I hope my changes to those .ad files are correct, if someone can test those architectures, that would be great. Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before (but never called), It is now called (and hopefully correct). I have tried to remove most parts of CMS. I have not made it a goal to remove all traces of CMS. I guess there are much more to cleanup, and suggestions of more to remove are welcomed. I think more complicated cleanups should be dealt with in separate enhancements. Not fully addressed in code, but an issue that has to be dealt with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be obsoleted, though I do not know if we have any precedence obsoleting -X options. My patch prints: $ java -Xconcgc -jar Notepad.jar Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC I guess that is not enough for being obsolete, compare with: $ java -XX:UseConcMarkSweepGC -jar Notepad.jar Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in 14.0 Bug: https://bugs.openjdk.java.net/browse/JDK-8232365 Webrev: http://cr.openjdk.java.net/~lkorinth/8232365/00 Testing: tier 1-5. Thanks, Leo From david.holmes at oracle.com Fri Oct 18 09:20:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2019 19:20:07 +1000 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <6cd3fae2-fc15-f17b-b475-38759e5860ac@oracle.com> Hi Leo, Picking up on one item ... > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. These flags (which are passed through from the launcher) are already marked as deprecated. So to "obsolete" them you just need to update the warning that gets issued (and otherwise delete them from the code). So you need to change this code in arguments.cpp to produce the appropriate obsoletion warning similar to what we issue for obsoleted -XX flags: // -Xconcgc } else if (match_option(option, "-Xconcgc")) { if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, true) != JVMFlag::SUCCESS) { return JNI_EINVAL; } handle_extra_cms_flags("-Xconcgc uses UseConcMarkSweepGC"); // -Xnoconcgc } else if (match_option(option, "-Xnoconcgc")) { if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, false) != JVMFlag::SUCCESS) { return JNI_EINVAL; } handle_extra_cms_flags("-Xnoconcgc uses UseConcMarkSweepGC"); Let me know if you need more details. Then file a follow up issue to remove these flags in the future. I don't know if you have a timeline for that yet. Cheers, David ----- On 18/10/2019 6:20 pm, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files > are correct, if someone can test those architectures, that would be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From david.holmes at oracle.com Fri Oct 18 09:38:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2019 19:38:35 +1000 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> Hi Leo, cc'ing build-dev. I think there is a process you need to follow to remove VM features from the build system. And build folk need to check all build changes anyway. Thanks, David On 18/10/2019 6:20 pm, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files > are correct, if someone can test those architectures, that would be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From erik.joelsson at oracle.com Fri Oct 18 12:54:41 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Oct 2019 05:54:41 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> Message-ID: <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> Hello Leo, When removing a JVM feature from the VALID_JVM_FEATURES list, it needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated here means removed here, but configure will still accept the argument (with a warning). Otherwise build changes look good. /Erik On 2019-10-18 02:38, David Holmes wrote: > Hi Leo, > > cc'ing build-dev. I think there is a process you need to follow to > remove VM features from the build system. And build folk need to check > all build changes anyway. > > Thanks, > David > > On 18/10/2019 6:20 pm, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that >> would be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal >> to remove all traces of CMS. I guess there are much more to cleanup, >> and suggestions of more to remove are welcomed. I think more >> complicated cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >> should be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ?? tier 1-5. >> >> Thanks, >> Leo From aleksei.voitylov at bell-sw.com Fri Oct 18 13:50:42 2019 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 18 Oct 2019 16:50:42 +0300 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <221404bb-432a-776c-f82d-595bdb363f9c@bell-sw.com> Leo, your changes build fine on aarch64, arm and ppc. This is not a full review. -Aleksei On 18/10/2019 11:20, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad > files are correct, if someone can test those architectures, that would > be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, > how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should > be obsoleted, though I do not know if we have any precedence > obsoleting -X options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses > UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From igor.ignatyev at oracle.com Fri Oct 18 15:45:30 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Oct 2019 08:45:30 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: Hi Leo, there are still some tests which can be cleaned up, e.g. test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_10_20/TestDescription.java has '@requires vm.gc != "ConcMarkSweep"'. it also makes sense to remove 'vm.gc.ConcMarkSweep' from requires.properties in TEST.ROOT files. -- Igor > On Oct 18, 2019, at 1:20 AM, Leo Korinth wrote: > > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files are correct, if someone can test those architectures, that would be great. > > Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to remove all traces of CMS. I guess there are much more to cleanup, and suggestions of more to remove are welcomed. I think more complicated cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be obsoleted, though I do not know if we have any precedence obsoleting -X options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > tier 1-5. > > Thanks, > Leo From sgehwolf at redhat.com Fri Oct 18 16:24:30 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Oct 2019 18:24:30 +0200 Subject: RFR: 8230305: Cgroups v2: Container awareness In-Reply-To: <072f66ee8c44034831b4e38f6470da4bff6edd07.camel@redhat.com> References: <072f66ee8c44034831b4e38f6470da4bff6edd07.camel@redhat.com> Message-ID: <7540a208e306ab957032b18178a53c6afa105d33.camel@redhat.com> On Tue, 2019-10-15 at 11:19 +0200, Severin Gehwolf wrote: > Hi, > > Please review this update to the container detection code which adds > cgroup version 2 support. Initial review of this started in [1]. Bob > preferred one big patch and didn't like the other refactoring in > os_linux so this has been dropped. > > This new patch includes both, the refactoring to move cgroup v1 > specific implementation out of osContainer_linux.{h,c}pp files[2] as > well as updated detection code and the implementation for cgroups > v2[3]. After this patch, osContainer_linux{h,c}pp files are cgroups > version agnostic. Implementations for specific versions are in > cgroupV{1,2}Subsystem.{c,h}pp files. Some shared, cgroup version > agnostic code is in cgroupSubsystem.{c,h}pp. > > Updated detection logic looks in /proc/cgroups first for hierarchy ids > of cpu/cpuset/cpuacct/memory controllers. If the hierarchy id for all > of them is 0 and they're all enabled, cgroups v2, unified hierarchy is > assumed. Otherwise it uses cgroups v1 controllers (also known as hybrid > or legacy hierarchy). Note that controllers can be only be mounted via > one or the other hierarchy, legacy (v1) or unified (v2) - exclusive[4]. > > Note that for the cgroups v2 cpu_shares() implementation a reverse > mapping is needed for the plain value exposed via cpu.weight. > Additionally, there doesn't seem to be an API exposed to use for an > implementation of memory_max_usage_in_bytes() in cgroups v2. Hence, it > returns OSCONTAINER_ERROR which is mapped to "not supported" elsewhere > in hotspot code. > > Once reviewed, I intend to push this in two changesets/bugs. One for > the refactoring work (no-op) as JDK-8230848. Another for the cgroupv2 > impl with JDK-8230305. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230305 Rebased webrev on top of JDK-8232207: http://cr.openjdk.java.net/~sgehwolf/webrevs/cgroupsv2-hotspot/03/webrev/ Thanks, Severin > > Testing: tier1 tests on Linux x86_64. Docker/podman hotspot tests on > F30 with hybrid cgroup v1 hierarchy. Hotspot container tests on F31 > with unified hierarchy on Linux x86_64. jdk/submit. All pass. > > Thoughts? > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039605.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039708.html > [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230848/04/webrev/ > [3] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/06/webrev/ > [4] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#mounting > "All controllers which support v2 and are not bound to a v1 hierarchy are > automatically bound to the v2 hierarchy and show up at the root. > Controllers which are not in active use in the v2 hierarchy can be > bound to other hierarchies." From ioi.lam at oracle.com Fri Oct 18 17:36:56 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 18 Oct 2019 10:36:56 -0700 Subject: Loading classes during VM shutdown Message-ID: For JDK-8232081 (Try to link all classes with ArchiveClassesAtExit), when creating a dynamic CDS archive, I need to link all classes in the "loaded" state. I am thinking of doing it at this point: src/java.base/share/classes/java/lang/Shutdown.java: ??? private static void runHooks() { ??????? synchronized (lock) { ??????????? /* Guard against the possibility of a daemon thread invoking exit ???????????? * after DestroyJavaVM initiates the shutdown sequence ???????????? */ ??????????? if (VM.isShutdown()) return; ??????? } ??????? for (int i=0; i < MAX_SYSTEM_HOOKS; i++) { ??????????? try { ??????????????? Runnable hook; ??????????????? synchronized (lock) { ??????????????????? // acquire the lock to make sure the hook registered during ??????????????????? // shutdown is visible here. ??????????????????? currentRunningHook = i; ??????????????????? hook = hooks[i]; ??????????????? } ??????????????? if (hook != null) hook.run(); ??????????? } catch (Throwable t) { ??????????????? if (t instanceof ThreadDeath) { ??????????????????? ThreadDeath td = (ThreadDeath)t; ??????????????????? throw td; ??????????????? } ??????????? } ??????? } + ? ? ? VM.linkClassesIfDumpingDynamicArchive(); <<<<<<<< ??????? // set shutdown state ??????? VM.shutdown(); ??? } To be safe, I will only link classes loaded by the built-in loaders (boot/platform/system). The reasons is linking classes may result in more class loading, which would execute Java code in the class loaders. I worry that arbitrary custom class loaders may not work well when executed in this context, but the built-in loader should be OK. After all, regular Shutdown hooks could (I think??) load classes .... Does anyone see a problem with doing this? Thanks - Ioi From forax at univ-mlv.fr Sat Oct 19 16:57:22 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 19 Oct 2019 18:57:22 +0200 (CEST) Subject: Remove support of old code attribute format Message-ID: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> Hi all, currently hotspot supports parsing a code attribute format [1] that is not described by the JVM spec if the major version is 45 and the minor <= 2. Obviously, none of the bytecode tools or other VMs support that format because it is not described in the JVMS (it predates Java), so it can be used to create classes that can not be inspected but run on hotspot. Someone named Chris ask us (ASM) to support that format [2], the same guy also asks for the support in javap see [3]. I think it's better to not change the VM spec but fix hotspot. Before logging a bug, i want to know what you guys are thinking about that. regards, R?mi [1] http://hg.openjdk.java.net/jdk/jdk/file/f7df2861be47/src/hotspot/share/classfile/classFileParser.cpp#l2451 [2] https://gitlab.ow2.org/asm/asm/issues/317888 [3] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8232598 From david.holmes at oracle.com Sun Oct 20 22:29:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Oct 2019 08:29:11 +1000 Subject: Loading classes during VM shutdown In-Reply-To: References: Message-ID: Hi Ioi, On 19/10/2019 3:36 am, Ioi Lam wrote: > For JDK-8232081 (Try to link all classes with ArchiveClassesAtExit), > when creating a dynamic CDS archive, I need to link all classes in the > "loaded" state. I am thinking of doing it at this point: > > src/java.base/share/classes/java/lang/Shutdown.java: > > ??? private static void runHooks() { > ??????? synchronized (lock) { > ??????????? /* Guard against the possibility of a daemon thread > invoking exit > ???????????? * after DestroyJavaVM initiates the shutdown sequence > ???????????? */ > ??????????? if (VM.isShutdown()) return; > ??????? } > > ??????? for (int i=0; i < MAX_SYSTEM_HOOKS; i++) { > ??????????? try { > ??????????????? Runnable hook; > ??????????????? synchronized (lock) { > ??????????????????? // acquire the lock to make sure the hook > registered during > ??????????????????? // shutdown is visible here. > ??????????????????? currentRunningHook = i; > ??????????????????? hook = hooks[i]; > ??????????????? } > ??????????????? if (hook != null) hook.run(); > ??????????? } catch (Throwable t) { > ??????????????? if (t instanceof ThreadDeath) { > ??????????????????? ThreadDeath td = (ThreadDeath)t; > ??????????????????? throw td; > ??????????????? } > ??????????? } > ??????? } > > + ? ? ? VM.linkClassesIfDumpingDynamicArchive(); <<<<<<<< > > ??????? // set shutdown state > ??????? VM.shutdown(); > ??? } > > To be safe, I will only link classes loaded by the built-in loaders > (boot/platform/system). The reasons is linking classes may result in > more class loading, which would execute Java code in the class loaders. > I worry that arbitrary custom class loaders may not work well when > executed in this context, but the built-in loader should be OK. After > all, regular Shutdown hooks could (I think??) load classes .... > > Does anyone see a problem with doing this? When you say "built-in" do you mean all of the boot/platform/app loaders? Any non-trivial execution of Java code could potentially have a bad interaction if run after shutdown hooks have completed. Cheers, David > Thanks > - Ioi From per.liden at oracle.com Mon Oct 21 07:43:10 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 21 Oct 2019 09:43:10 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> Message-ID: <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Hi Erik, On 10/18/19 2:54 PM, Erik Joelsson wrote: > Hello Leo, > > When removing a JVM feature from the VALID_JVM_FEATURES list, it needs > to be added to the DEPRECATED_JVM_FEATURES list. Deprecated here means > removed here, but configure will still accept the argument (with a > warning). Are we really treating the list of JVM feature as a public/stable API, or is there some other reason for this? Would the plan be to remove it from the DEPRECATED_JVM_FEATURES in JDK 15? cheers, Per > > Otherwise build changes look good. > > /Erik > > On 2019-10-18 02:38, David Holmes wrote: >> Hi Leo, >> >> cc'ing build-dev. I think there is a process you need to follow to >> remove VM features from the build system. And build folk need to check >> all build changes anyway. >> >> Thanks, >> David >> >> On 18/10/2019 6:20 pm, Leo Korinth wrote: >>> Hi, >>> >>> Here is a patch that removes the CMS GC. >>> >>> I have neither tested arm nor ppc; I hope my changes to those .ad >>> files are correct, if someone can test those architectures, that >>> would be great. >>> >>> Please take an extra look at >>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >>> (but never called), It is now called (and hopefully correct). >>> >>> I have tried to remove most parts of CMS. I have not made it a goal >>> to remove all traces of CMS. I guess there are much more to cleanup, >>> and suggestions of more to remove are welcomed. I think more >>> complicated cleanups should be dealt with in separate enhancements. >>> >>> Not fully addressed in code, but an issue that has to be dealt with, >>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >>> should be obsoleted, though I do not know if we have any precedence >>> obsoleting -X options. >>> >>> My patch prints: >>> >>> $ java -Xconcgc -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>> UseConcMarkSweepGC >>> >>> I guess that is not enough for being obsolete, compare with: >>> >>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>> UseConcMarkSweepGC; support was removed in 14.0 >>> >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>> >>> Webrev: >>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>> >>> Testing: >>> ?? tier 1-5. >>> >>> Thanks, >>> Leo From magnus.ihse.bursie at oracle.com Mon Oct 21 09:46:15 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Oct 2019 11:46:15 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Message-ID: On 2019-10-21 09:43, Per Liden wrote: > Hi Erik, > > On 10/18/19 2:54 PM, Erik Joelsson wrote: >> Hello Leo, >> >> When removing a JVM feature from the VALID_JVM_FEATURES list, it >> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >> here means removed here, but configure will still accept the argument >> (with a warning). > > Are we really treating the list of JVM feature as a public/stable API, > or is there some other reason for this? Would the plan be to remove it > from the DEPRECATED_JVM_FEATURES in JDK 15? Note that this is an issue for building only. A feature listed as deprecated in the build will not propagate outside the build system. We are basically treating the configure command line arguments as a "stable API". The intention is that a command line on a build script should not cause a build failure due to an unknown argument. We have traditionally had 2-3 major releases before removing deprecated command line options. /Magnus > > cheers, > Per > >> >> Otherwise build changes look good. >> >> /Erik >> >> On 2019-10-18 02:38, David Holmes wrote: >>> Hi Leo, >>> >>> cc'ing build-dev. I think there is a process you need to follow to >>> remove VM features from the build system. And build folk need to >>> check all build changes anyway. >>> >>> Thanks, >>> David >>> >>> On 18/10/2019 6:20 pm, Leo Korinth wrote: >>>> Hi, >>>> >>>> Here is a patch that removes the CMS GC. >>>> >>>> I have neither tested arm nor ppc; I hope my changes to those .ad >>>> files are correct, if someone can test those architectures, that >>>> would be great. >>>> >>>> Please take an extra look at >>>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy >>>> before (but never called), It is now called (and hopefully correct). >>>> >>>> I have tried to remove most parts of CMS. I have not made it a goal >>>> to remove all traces of CMS. I guess there are much more to >>>> cleanup, and suggestions of more to remove are welcomed. I think >>>> more complicated cleanups should be dealt with in separate >>>> enhancements. >>>> >>>> Not fully addressed in code, but an issue that has to be dealt >>>> with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the >>>> option should be obsoleted, though I do not know if we have any >>>> precedence obsoleting -X options. >>>> >>>> My patch prints: >>>> >>>> $ java -Xconcgc -jar Notepad.jar >>>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>>> UseConcMarkSweepGC >>>> >>>> I guess that is not enough for being obsolete, compare with: >>>> >>>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>>> UseConcMarkSweepGC; support was removed in 14.0 >>>> >>>> Bug: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>>> >>>> Webrev: >>>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>>> >>>> Testing: >>>> ?? tier 1-5. >>>> >>>> Thanks, >>>> Leo From leo.korinth at oracle.com Mon Oct 21 12:48:45 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Oct 2019 14:48:45 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: On 18/10/2019 17:45, Igor Ignatyev wrote: > Hi Leo, > > there are still some tests which can be cleaned up, e.g. test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_10_20/TestDescription.java has '@requires vm.gc != "ConcMarkSweep"'. it also makes sense to remove 'vm.gc.ConcMarkSweep' from requires.properties in TEST.ROOT files. > > -- Igor Thanks! I have cleaned up four occurrences '@requires vm.gc != "ConcMarkSweep"' as well as removed vm.gc.ConcMarkSweep from TEST.ROOT. /Leo > >> On Oct 18, 2019, at 1:20 AM, Leo Korinth wrote: >> >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad files are correct, if someone can test those architectures, that would be great. >> >> Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to remove all traces of CMS. I guess there are much more to cleanup, and suggestions of more to remove are welcomed. I think more complicated cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be obsoleted, though I do not know if we have any precedence obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> tier 1-5. >> >> Thanks, >> Leo > From leo.korinth at oracle.com Mon Oct 21 12:55:34 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Oct 2019 14:55:34 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <221404bb-432a-776c-f82d-595bdb363f9c@bell-sw.com> References: <221404bb-432a-776c-f82d-595bdb363f9c@bell-sw.com> Message-ID: On 18/10/2019 15:50, Aleksei Voitylov wrote: > Leo, > > your changes build fine on aarch64, arm and ppc. This is not a full review. > > -Aleksei Good, thanks for testing! /Leo > > On 18/10/2019 11:20, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that would >> be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to >> remove all traces of CMS. I guess there are much more to cleanup, and >> suggestions of more to remove are welcomed. I think more complicated >> cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should >> be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ? tier 1-5. >> >> Thanks, >> Leo From erik.joelsson at oracle.com Mon Oct 21 15:45:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Oct 2019 08:45:30 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> Message-ID: <94194567-430c-97df-2e96-fe895123311a@oracle.com> On 2019-10-21 02:46, Magnus Ihse Bursie wrote: > On 2019-10-21 09:43, Per Liden wrote: >> Hi Erik, >> >> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>> Hello Leo, >>> >>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>> here means removed here, but configure will still accept the >>> argument (with a warning). >> >> Are we really treating the list of JVM feature as a public/stable >> API, or is there some other reason for this? Would the plan be to >> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? > > Note that this is an issue for building only. A feature listed as > deprecated in the build will not propagate outside the build system. > > We are basically treating the configure command line arguments as a > "stable API". The intention is that a command line on a build script > should not cause a build failure due to an unknown argument. We have > traditionally had 2-3 major releases before removing deprecated > command line options. > We (or at least I) have been a bit lazy with removing the deprecated args. I wouldn't mind being a bit more aggressive. /Erik From leo.korinth at oracle.com Mon Oct 21 17:56:51 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 21 Oct 2019 19:56:51 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <6cd3fae2-fc15-f17b-b475-38759e5860ac@oracle.com> References: <6cd3fae2-fc15-f17b-b475-38759e5860ac@oracle.com> Message-ID: On 18/10/2019 11:20, David Holmes wrote: > Hi Leo, > > Picking up on one item ... > > > Not fully addressed in code, but an issue that has to be dealt with, how > > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > > obsoleted, though I do not know if we have any precedence obsoleting -X > > options. > > These flags (which are passed through from the launcher) are already > marked as deprecated. So to "obsolete" them you just need to update the > warning that gets issued (and otherwise delete them from the code). So > you need to change this code in arguments.cpp to produce the appropriate > obsoletion warning similar to what we issue for obsoleted -XX flags: > > ?? // -Xconcgc > ??? } else if (match_option(option, "-Xconcgc")) { > ????? if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, true) != > JVMFlag::SUCCESS) { > ??????? return JNI_EINVAL; > ????? } > ????? handle_extra_cms_flags("-Xconcgc uses UseConcMarkSweepGC"); > ??? // -Xnoconcgc > ??? } else if (match_option(option, "-Xnoconcgc")) { > ????? if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, false) != > JVMFlag::SUCCESS) { > ??????? return JNI_EINVAL; > ????? } > ????? handle_extra_cms_flags("-Xnoconcgc uses UseConcMarkSweepGC"); > > Let me know if you need more details. > > Then file a follow up issue to remove these flags in the future. I don't > know if you have a timeline for that yet. > > Cheers, > David > ----- Hi David, I filed https://bugs.openjdk.java.net/browse/JDK-8232739 Do you suggest something like this? diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp index 620168b4e4b..c0a9acea962 100644 --- a/src/hotspot/share/runtime/arguments.cpp +++ b/src/hotspot/share/runtime/arguments.cpp @@ -2615,10 +2615,10 @@ jint Arguments::parse_each_vm_init_arg(const JavaVMInitArgs* args, bool* patch_m } // -Xconcgc } else if (match_option(option, "-Xconcgc")) { - handle_extra_cms_flags("-Xconcgc uses UseConcMarkSweepGC"); + warning("-Xconcgc uses UseConcMarkSweepGC; support was removed for both options in 14.0"); // -Xnoconcgc } else if (match_option(option, "-Xnoconcgc")) { - handle_extra_cms_flags("-Xnoconcgc uses UseConcMarkSweepGC"); + warning("-Xnoconcgc uses UseConcMarkSweepGC; support was removed for both options in 14.0"); // -Xbatch } else if (match_option(option, "-Xbatch")) { if (FLAG_SET_CMDLINE(BackgroundCompilation, false) != JVMFlag::SUCCESS) { @@ -3859,15 +3859,6 @@ bool Arguments::handle_deprecated_print_gc_flags() { return true; } -void Arguments::handle_extra_cms_flags(const char* msg) { - SpecialFlag flag; - const char *flag_name = "UseConcMarkSweepGC"; - if (lookup_special_flag(flag_name, flag)) { - handle_aliases_and_deprecation(flag_name, /* print warning */ true); - warning("%s", msg); - } -} - // Parse entry point called from JNI_CreateJavaVM jint Arguments::parse(const JavaVMInitArgs* initial_cmd_args) { diff --git a/src/hotspot/share/runtime/arguments.hpp b/src/hotspot/share/runtime/arguments.hpp index d9aa77af315..2759836bb88 100644 --- a/src/hotspot/share/runtime/arguments.hpp +++ b/src/hotspot/share/runtime/arguments.hpp @@ -425,8 +425,6 @@ class Arguments : AllStatic { static bool handle_deprecated_print_gc_flags(); - static void handle_extra_cms_flags(const char* msg); - static jint parse_vm_init_args(const JavaVMInitArgs *java_tool_options_args, const JavaVMInitArgs *java_options_args, const JavaVMInitArgs *cmd_line_args); Thanks, Leo > > On 18/10/2019 6:20 pm, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that would >> be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to >> remove all traces of CMS. I guess there are much more to cleanup, and >> suggestions of more to remove are welcomed. I think more complicated >> cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should >> be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ?? tier 1-5. >> >> Thanks, >> Leo From coleen.phillimore at oracle.com Mon Oct 21 18:08:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 21 Oct 2019 14:08:21 -0400 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: On 10/18/19 4:20 AM, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad > files are correct, if someone can test those architectures, that would > be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. I can send you a list of things extra things I know about.? Thank you for not addressing all of the CMS special cases with this patch. http://cr.openjdk.java.net/~lkorinth/8232365/00/src/hotspot/share/oops/oop.inline.hpp.udiff.html This set_klass_to_list_ptr was an especially aggregious type violation.? Since you've touched this, can you remove these functions with your patch: ? // For when the klass pointer is being used as a linked list "next" field. ? inline void set_klass_to_list_ptr(oop k); ? inline oop list_ptr_from_klass(); The runtime and oops changes look good. Coleen > > Not fully addressed in code, but an issue that has to be dealt with, > how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should > be obsoleted, though I do not know if we have any precedence > obsoleting -X options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses > UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From kim.barrett at oracle.com Mon Oct 21 21:48:46 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Oct 2019 17:48:46 -0400 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: > On Oct 18, 2019, at 4:20 AM, Leo Korinth wrote: > > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files are correct, if someone can test those architectures, that would be great. > > Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to remove all traces of CMS. I guess there are much more to cleanup, and suggestions of more to remove are welcomed. I think more complicated cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be obsoleted, though I do not know if we have any precedence obsoleting -X options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > tier 1-5. > > Thanks, > Leo Looks pretty good. A fair number of comments below, but no major problems, just tidying things up. I'm sure there are more lingering CMS-isms, but we can clean those up in followups. (After all, there are still lingering permgen bits here and there, at least in comments.) Regarding obsoleting -X options, you might look at what was done for -Xincgc (JEP 214 - JDK-8044022, JDK-8072921). Regarding CollectedHeap::check_for_non_bad_heap_word_value, bleh! The first couple of comments below are about it. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/collectedHeap.cpp 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { ... 338 // please not mismatch between size (in 32/64 bit words), and ju_addr that always point to a 32 bit word s/not/note/ Also, the assert on 340 looks indented 3 rather than 2. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/collectedHeap.cpp 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { > Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, > it was buggy before (but never called), It is now called (and hopefully > correct). I don't understand "but never called" as it looks like it has been called all along from MemAllocator::allocate_outside_tlab. Except that's only when UseTLAB is false, and it always defaults true if any of C1, C2, or JVMCI are included. We do have some -UseTLAB tests though, and they aren't all with CMS, so I'm not sure how a problem here hasn't already appeared. Because I don't understand "but never called" I'm failing to understand how this hasn't shown up as a problem before. Seems like it should never have worked and there would be test failures at least. Part of the problem here is that Copy::fill_to_words takes a juint fill value that it duplicates in high/low on 64bit platforms. That seems wrong; shouldn't it take a platform-word sized value and just store that? But making any such change is going to require some care. And it results in the CollectedHeap implementation's use of intptr_t on 64bit platforms comparing badHeapWord (a juint, so 32bits) with 64bit (((julong)badHeapWord << 32) | badHeapWord). So how did this ever manage to pass testing? However, on a 64bit platform the new code (and the old GenCollectedHeap code) is only checking every other 32bit value. The step distance is 8 bytes but the value read at each step is only 4 bytes. There is also a (pre-existing) !PRODUCT vs ASSERT mismatch here. The checker is !PRODUCT, but the filling is debug-only (see SpaceMangler::mangle_region). So I think it's still broken in "optimized" builds. (It is periodically suggested that we get rid of that configuration (JDK-8183287, for example) but there's always been some folks who really want to keep it.) ------------------------------------------------------------------------------ src/hotspot/cpu/arm/globals_arm.hpp 66 // GC Ergo Flags I think that comment only applied to the now removed CMSYoungGenPerWorker. It now _appears_ to apply to TypeProfileLevel, which isn't a GC flag. Suggest just removing the comment. Similarly in (all?) the other globals_.hpp files: src/hotspot/cpu/aarch64/globals_aarch64.hpp src/hotspot/cpu/ppc/globals_ppc.hpp src/hotspot/cpu/s390/globals_s390.hpp src/hotspot/cpu/sparc/globals_sparc.hpp src/hotspot/cpu/x86/globals_x86.hpp src/hotspot/cpu/zero/globals_zero.hpp ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp 301 * in the nursery, this would happen for humongous objects. This is similar to 302 * how CMS was required to handle this case, see the comments for the method 303 * CollectedHeap::new_deferred_store_barrier and OptoRuntime::new_deferred_store_barrier. I would prefer this didn't mention CMS at all anymore, e.g. drop the phase "This is similar to how CMS was required to handle this case". But while exploring this I discovered that the functions being referred to here no longer exist, at least not by that name. That is, there are no occurrences of "new_deferred_store_barrier" other than in some comments. I haven't tried to figure out what's happened beyond noticing that... ------------------------------------------------------------------------------ src/hotspot/share/gc/parallel/psPromotionManager.hpp 105 // need to scan; this is basically how ParNew did partial array 106 // scanning too). To be able to distinguish between reference I would prefer this didn't mention ParNew at all anymore, e.g. drop everything after the semicolon. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/blockOffsetTable.hpp 44 // - BlockOffsetArrayNonContigSpace Doesn't exist anymore. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/cardTableBarrierSet.cpp 117 // but, like in CMS, because of the presence of concurrent refinement 118 // (much like CMS' precleaning), must strictly follow the oop-store. 119 // Thus, using the same protocol for maintaining the intended 120 // invariants turns out, serendepitously, to be the same for both 121 // G1 and CMS. I'd prefer this didn't mention CMS anymore, e.g. s/, like in CMS,// s/(much like CMS' precleaning)// s/Thus, ...// ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp 68 // As ConcGCThreads should be smaller than ParallelGCThreads, 69 // we need constraint function. 70 JVMFlag::Error ConcGCThreadsConstraintFunc(uint value, bool verbose) { 71 // G1 GC use ConcGCThreads. 72 if (GCConfig::is_gc_selected(CollectedHeap::G1) && (value > ParallelGCThreads)) { Other collectors (Shenandoah and Z) also use ConcGCThreads. I don't know if ConcGCThreads is supposed to be not greater than ParallelGCThreads for those collectors. It might be a bug that this code was checking for specific GCs here (formerly G1 and CMS, now just G1). (I _think_ this code might pre-date both Shenandoah and Z, at least in open code.) There are some other constraint functions that are checking for specific GCs that maybe ought not to be. Looking into this and doing any further changes should be deferred to a separate RFE rather than trying to include in this CMS removal change. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/referenceProcessor.hpp 220 // of an oop. It is currently initialized to NULL for all 221 // collectors except for G1. It might be better to leave out the last sentence. Shenandoah uses _is_alive_non_header too, though initialized to NULL and manipulated where needed using ReferenceProcessorIsAliveMutator. ------------------------------------------------------------------------------ src/hotspot/share/oops/markWord.hpp 130 static const int unused_gap_bits = LP64_ONLY(1) NOT_LP64(0); ... 138 static const int unused_gap_shift = age_shift + age_bits; 139 static const int hash_shift = unused_gap_shift + unused_gap_bits; For this change, I completely agree with this renaming of CMS bits to "unused_gap". Moving header bits around seems likely to have lots of "interesting" effects. I assume there will be a followup RFE to clean this up? ------------------------------------------------------------------------------ src/hotspot/share/runtime/arguments.cpp 73 product options bite the dust! ------------------------------------------------------------------------------ src/hotspot/share/runtime/arguments.cpp 4177 // Non NUMA-aware collectors such as G1 and Serial-GC on FYI, there will be a minor merge conflict here between you and Sangheon's G1 NUMA changes. ------------------------------------------------------------------------------ I only skimmed the Serviceability Agent changes. They look ok, but I'm not very familiar with that code, so don't count me as having reviewed that part. ------------------------------------------------------------------------------ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java 234 Parallel(true, "UseParallelGC", "UseParallelOldGC"), You removed UseParNewGC from here. Seems like that use was just wrong. -XX:+UseParNewGC alone was ParNew + SerialOld (so nothing to do with "ParallelGC"), and that combination and usage was deprecated in JDK 8 (JEP 173) and removed in JDK 9 (JEP 214). The UseParNewGC doesn't even exist anymore. So good find! Could have been a separate bug, but doesn't seem worth the effort now. ------------------------------------------------------------------------------ test/hotspot/jtreg/runtime/7167069/PrintAsFlag.java Removal of -XX:CMSSmallCoalSurplusPercent=1.05 leaves no floating point flags in the command, so that case is no longer covered. ------------------------------------------------------------------------------ test/hotspot/jtreg/runtime/testlibrary/ClassUnloadCommon.java 65 allocateMemory(16 * 1024); // yg size is 8m with cms[[keep?]], force young collection This looks like a lingering TODO for this change. ------------------------------------------------------------------------------ test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/TestDriver.java 48 * is enabled and G1 is enbled. If ExplicitGCInvokesConcurrent and 49 * G1 is enbled the test searches for 'GC' string in output. [pre-existing, but since you are touching these lines anyway...] s/enbled/enabled/ -- two occurrences [and another pre-existing problem nearby] This line: 47 * searched for 'Full GC' string, unless ExplicitGCInvokesConcurrent doesn't match the code here: 86 keyPhrase = "Pause Full"; ------------------------------------------------------------------------------ test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java Removed: 28 * @comment Graal does not support CMS 29 * @requires !vm.graal.enabled This @requires was disabling this test for all collectors when graal was enabled, not just for CMS. Has this been run with graal and all other GCs? ------------------------------------------------------------------------------ test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java 66 "-XX:+UseConcMarkSweepGC", // this will cause MaxNewSize to be FLAG_SET_ERGO => 64 "-XX:+UseConcG1GC", // this will cause MaxNewSize to be FLAG_SET_ERGO Seems like this should be using +UseG1GC. (Not relying on this bogus option being ignored and defaulting to G1, and not having anything to do with the comment.) ------------------------------------------------------------------------------ test/jdk/java/lang/management/MemoryMXBean/PendingAllGC.sh Maybe this test should be updated to test with other collectors than just the default (now G1) and Parallel. File an RFE? ------------------------------------------------------------------------------ test/jdk/jdk/jfr/event/gc/collection/GCEventAll.java 243 if (GCHelper.gcG1Old.equals(oldCollector)) { 244 // ConcurrentMarkSweep mixes old and new collections. Not same values as in MXBean. 245 // MXBean does not report old collections for G1Old, so we have nothing to compare with. 246 return; 247 } Comment also needed to be updated. ------------------------------------------------------------------------------ test/jdk/jdk/jfr/event/oldobject/TestMetadataRetention.java 90 // System.gc() will trigger class unloading if -XX:+ExplicitGCInvokesConcurrent 91 // is NOT set. If this flag is set G1 will never unload classes on System.gc(). I think this comment is no longer true. If this test doesn't work with -ExplicitGCInvokesConcurrent then that should be filtered in an @requires check. I don't know if it doesn't work though. I don't know what this part of the comment means though: 92 // As far as the "jfr" key guarantees no VM flags are set from the 93 // outside it should be enough with System.gc(). I assume it's referring to the "@key jfr" line in the @test description. But I don't know what that does. Similarly in these: test/jdk/jdk/jfr/event/runtime/TestClassLoadingStatisticsEvent.java test/jdk/jdk/jfr/event/runtime/TestClassUnloadEvent.java ------------------------------------------------------------------------------ From david.holmes at oracle.com Mon Oct 21 22:57:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2019 08:57:07 +1000 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <6cd3fae2-fc15-f17b-b475-38759e5860ac@oracle.com> Message-ID: <152cde0e-f466-651e-7ed7-668dfa85f46b@oracle.com> On 22/10/2019 3:56 am, Leo Korinth wrote: > On 18/10/2019 11:20, David Holmes wrote: >> Hi Leo, >> >> Picking up on one item ... >> >> ?> Not fully addressed in code, but an issue that has to be dealt >> with, how >> ?> do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be >> ?> obsoleted, though I do not know if we have any precedence >> obsoleting -X >> ?> options. >> >> These flags (which are passed through from the launcher) are already >> marked as deprecated. So to "obsolete" them you just need to update >> the warning that gets issued (and otherwise delete them from the >> code). So you need to change this code in arguments.cpp to produce the >> appropriate obsoletion warning similar to what we issue for obsoleted >> -XX flags: >> >> ??? // -Xconcgc >> ???? } else if (match_option(option, "-Xconcgc")) { >> ?????? if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, true) != >> JVMFlag::SUCCESS) { >> ???????? return JNI_EINVAL; >> ?????? } >> ?????? handle_extra_cms_flags("-Xconcgc uses UseConcMarkSweepGC"); >> ???? // -Xnoconcgc >> ???? } else if (match_option(option, "-Xnoconcgc")) { >> ?????? if (FLAG_SET_CMDLINE(UseConcMarkSweepGC, false) != >> JVMFlag::SUCCESS) { >> ???????? return JNI_EINVAL; >> ?????? } >> ?????? handle_extra_cms_flags("-Xnoconcgc uses UseConcMarkSweepGC"); >> >> Let me know if you need more details. >> >> Then file a follow up issue to remove these flags in the future. I >> don't know if you have a timeline for that yet. >> >> Cheers, >> David >> ----- > > > Hi David, I filed https://bugs.openjdk.java.net/browse/JDK-8232739 > > Do you suggest something like this? Yes just like that. Thanks, David ----- > > diff --git a/src/hotspot/share/runtime/arguments.cpp > b/src/hotspot/share/runtime/arguments.cpp > index 620168b4e4b..c0a9acea962 100644 > --- a/src/hotspot/share/runtime/arguments.cpp > +++ b/src/hotspot/share/runtime/arguments.cpp > @@ -2615,10 +2615,10 @@ jint Arguments::parse_each_vm_init_arg(const > JavaVMInitArgs* args, bool* patch_m > ?????? } > ???? // -Xconcgc > ???? } else if (match_option(option, "-Xconcgc")) { > -????? handle_extra_cms_flags("-Xconcgc uses UseConcMarkSweepGC"); > +????? warning("-Xconcgc uses UseConcMarkSweepGC; support was removed > for both options in 14.0"); > ???? // -Xnoconcgc > ???? } else if (match_option(option, "-Xnoconcgc")) { > -????? handle_extra_cms_flags("-Xnoconcgc uses UseConcMarkSweepGC"); > +????? warning("-Xnoconcgc uses UseConcMarkSweepGC; support was removed > for both options in 14.0"); > ???? // -Xbatch > ???? } else if (match_option(option, "-Xbatch")) { > ?????? if (FLAG_SET_CMDLINE(BackgroundCompilation, false) != > JVMFlag::SUCCESS) { > @@ -3859,15 +3859,6 @@ bool Arguments::handle_deprecated_print_gc_flags() { > ?? return true; > ?} > > -void Arguments::handle_extra_cms_flags(const char* msg) { > -? SpecialFlag flag; > -? const char *flag_name = "UseConcMarkSweepGC"; > -? if (lookup_special_flag(flag_name, flag)) { > -??? handle_aliases_and_deprecation(flag_name, /* print warning */ true); > -??? warning("%s", msg); > -? } > -} > - > ?// Parse entry point called from JNI_CreateJavaVM > > ?jint Arguments::parse(const JavaVMInitArgs* initial_cmd_args) { > diff --git a/src/hotspot/share/runtime/arguments.hpp > b/src/hotspot/share/runtime/arguments.hpp > index d9aa77af315..2759836bb88 100644 > --- a/src/hotspot/share/runtime/arguments.hpp > +++ b/src/hotspot/share/runtime/arguments.hpp > @@ -425,8 +425,6 @@ class Arguments : AllStatic { > > ?? static bool handle_deprecated_print_gc_flags(); > > -? static void handle_extra_cms_flags(const char* msg); > - > ?? static jint parse_vm_init_args(const JavaVMInitArgs > *java_tool_options_args, > ????????????????????????????????? const JavaVMInitArgs *java_options_args, > ????????????????????????????????? const JavaVMInitArgs *cmd_line_args); > > > Thanks, > Leo > >> >> On 18/10/2019 6:20 pm, Leo Korinth wrote: >>> Hi, >>> >>> Here is a patch that removes the CMS GC. >>> >>> I have neither tested arm nor ppc; I hope my changes to those .ad >>> files are correct, if someone can test those architectures, that >>> would be great. >>> >>> Please take an extra look at >>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >>> (but never called), It is now called (and hopefully correct). >>> >>> I have tried to remove most parts of CMS. I have not made it a goal >>> to remove all traces of CMS. I guess there are much more to cleanup, >>> and suggestions of more to remove are welcomed. I think more >>> complicated cleanups should be dealt with in separate enhancements. >>> >>> Not fully addressed in code, but an issue that has to be dealt with, >>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >>> should be obsoleted, though I do not know if we have any precedence >>> obsoleting -X options. >>> >>> My patch prints: >>> >>> $ java -Xconcgc -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>> UseConcMarkSweepGC >>> >>> I guess that is not enough for being obsolete, compare with: >>> >>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>> UseConcMarkSweepGC; support was removed in 14.0 >>> >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>> >>> Webrev: >>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>> >>> Testing: >>> ?? tier 1-5. >>> >>> Thanks, >>> Leo From forax at univ-mlv.fr Mon Oct 21 23:32:54 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 22 Oct 2019 01:32:54 +0200 (CEST) Subject: Remove support of old code attribute format In-Reply-To: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> References: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> Message-ID: <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> *ping* ----- Mail original ----- > De: "Remi Forax" > ?: "hotspot-dev" > Envoy?: Samedi 19 Octobre 2019 18:57:22 > Objet: Remove support of old code attribute format > Hi all, > currently hotspot supports parsing a code attribute format [1] that is not > described by the JVM spec if the major version is 45 and the minor <= 2. > > Obviously, none of the bytecode tools or other VMs support that format because > it is not described in the JVMS (it predates Java), > so it can be used to create classes that can not be inspected but run on > hotspot. > > Someone named Chris ask us (ASM) to support that format [2], the same guy also > asks for the support in javap see [3]. > > I think it's better to not change the VM spec but fix hotspot. > > Before logging a bug, i want to know what you guys are thinking about that. > > regards, > R?mi > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/f7df2861be47/src/hotspot/share/classfile/classFileParser.cpp#l2451 > [2] https://gitlab.ow2.org/asm/asm/issues/317888 > [3] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8232598 From mark.reinhold at oracle.com Tue Oct 22 03:22:53 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 21 Oct 2019 20:22:53 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options Message-ID: <20191021202253.825695282@eggemoggin.niobe.net> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ This change implements jlink plugins, and associated changes in the VM and libraries, to support the following new jlink options: - --vendor-bug-url= overrides the vendor bug URL baked into the build. The value of the system property "java.vendor.url.bug" will be . - --vendor-vm-bug-url= overrides the vendor VM bug URL baked into the build. This value will be displayed in VM error logs. - --vendor-version= overrides the vendor version string baked into the build, if any. The value of the system property "java.vendor.version" will be . This value will be displayed in the output of java --version. - --add-options= prepends the specified string, which may include whitespace, before any other options when invoking the VM in the resulting image. The vendor-information plugins work by using the JDK?s internal ASM library to redefine static fields in the java.lang.VersionProps class. The VM reads the vendor-version and vendor-vm-bug-url strings from that class during startup. The add-options plugin works by storing the requested options in an internal resource, /java.base/jdk/internal/vm/options. The VM loads that resource from the lib/modules jimage file during startup and prepends any options found there to those given on the command line. Passes tier1-3 and JCK on {linux,macos,windows}-x64. Thanks, - Mark From magnus.ihse.bursie at oracle.com Tue Oct 22 07:17:52 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 09:17:52 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot Message-ID: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> The -Wextra option to gcc enables a bunch of useful warnings. Some of them, but not all, can be individually enabled or disabled. All other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. Enabling -Wextra triggers a couple of warnings that can be individually disabled. (The idea here is not to just permanently disable those warnings (unless that makes sense), but to look at these warnings one at a time and see how they can be addressed.) My trial runs with -Wextra has already found a couple of real issues (fixed in JDK-8213414). I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 /Magnus From david.holmes at oracle.com Tue Oct 22 07:36:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2019 17:36:13 +1000 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> Hi Magnus, On 22/10/2019 5:17 pm, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings. Some of > them, but not all, can be individually enabled or disabled. All other > libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra triggers a couple of warnings that can be individually > disabled. (The idea here is not to just permanently disable those > warnings (unless that makes sense), but to look at these warnings one at > a time and see how they can be addressed.) > > My trial runs with -Wextra has already found a couple of real issues > (fixed in JDK-8213414). > > I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, > 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and > arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 I'm somewhat surprised that this isn't triggering more warnings, but if not then that is a good thing. :) I wouldn't be surprised if gcc 9.x causes something else pop up. Fix seems fine. Thanks, David > > /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 22 08:28:02 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 10:28:02 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> <74b45837-3ba0-9bb9-0336-69cccc77adcc@oracle.com> Message-ID: <3eccb4dd-1721-431e-d491-416850b43ec5@oracle.com> On 2019-10-22 09:36, David Holmes wrote: > Hi Magnus, > > On 22/10/2019 5:17 pm, Magnus Ihse Bursie wrote: >> The -Wextra option to gcc enables a bunch of useful warnings. Some of >> them, but not all, can be individually enabled or disabled. All other >> libraries in OpenJDK are compiled with -Wextra, but not Hotspot. >> Enabling -Wextra triggers a couple of warnings that can be >> individually disabled. (The idea here is not to just permanently >> disable those warnings (unless that makes sense), but to look at >> these warnings one at a time and see how they can be addressed.) >> >> My trial runs with -Wextra has already found a couple of real issues >> (fixed in JDK-8213414). >> >> I have tested that this compiles without warnings on gcc 4.8, 5.5, >> 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, >> aarch64 and arm32 with gcc 8.3. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > > > I'm somewhat surprised that this isn't triggering more warnings, but > if not then that is a good thing. :) I wouldn't be surprised if gcc > 9.x causes something else pop up. That is because I enabled it in a personal branch a long time ago, and have spent like the last year or so trying to fix the individual problems to prepare for this patch. ;-) I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. /Magnus > > Fix seems fine. > > Thanks, > David > >> >> /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 22 09:45:41 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Oct 2019 11:45:41 +0200 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 2019-10-22 05:22, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ Build changes look good. /Magnus > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark From Alan.Bateman at oracle.com Tue Oct 22 14:15:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Oct 2019 15:15:10 +0100 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 22/10/2019 04:22, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ I've read through the code for the new jlink plugins and the changes to VersionProps and it looks good. An alternative for VersionProps would have been to generate a helper class at link time rather than extending the static initilizer to set the fields. That would allow the VENDOR* fields to be final (but I don't think it makes too much difference and it may be a bit more complicated due to having 4 plugins contributing code). The need for a plugin per CLI option may be motivation to explore (in the future) having a single plugin expose multiple options. -Alan From harold.seigel at oracle.com Tue Oct 22 14:55:30 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 22 Oct 2019 10:55:30 -0400 Subject: Remove support of old code attribute format In-Reply-To: <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> References: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Could you enter a bug for this problem? Thanks, Harold On 10/21/2019 7:32 PM, Remi Forax wrote: > *ping* > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "hotspot-dev" >> Envoy?: Samedi 19 Octobre 2019 18:57:22 >> Objet: Remove support of old code attribute format >> Hi all, >> currently hotspot supports parsing a code attribute format [1] that is not >> described by the JVM spec if the major version is 45 and the minor <= 2. >> >> Obviously, none of the bytecode tools or other VMs support that format because >> it is not described in the JVMS (it predates Java), >> so it can be used to create classes that can not be inspected but run on >> hotspot. >> >> Someone named Chris ask us (ASM) to support that format [2], the same guy also >> asks for the support in javap see [3]. >> >> I think it's better to not change the VM spec but fix hotspot. >> >> Before logging a bug, i want to know what you guys are thinking about that. >> >> regards, >> R?mi >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/f7df2861be47/src/hotspot/share/classfile/classFileParser.cpp#l2451 >> [2] https://gitlab.ow2.org/asm/asm/issues/317888 >> [3] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8232598 From leo.korinth at oracle.com Tue Oct 22 15:17:09 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 22 Oct 2019 17:17:09 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <1c57c422-2b29-d5e7-ac72-17cbaedd073a@oracle.com> On 21/10/2019 23:48, Kim Barrett wrote: >> On Oct 18, 2019, at 4:20 AM, Leo Korinth wrote: >> >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad files are correct, if someone can test those architectures, that would be great. >> >> Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to remove all traces of CMS. I guess there are much more to cleanup, and suggestions of more to remove are welcomed. I think more complicated cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be obsoleted, though I do not know if we have any precedence obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> tier 1-5. >> >> Thanks, >> Leo > > Looks pretty good. > > A fair number of comments below, but no major problems, just tidying > things up. > > I'm sure there are more lingering CMS-isms, but we can clean those up > in followups. (After all, there are still lingering permgen bits here > and there, at least in comments.) > > Regarding obsoleting -X options, you might look at what was done for > -Xincgc (JEP 214 - JDK-8044022, JDK-8072921). Thanks. > Regarding CollectedHeap::check_for_non_bad_heap_word_value, bleh! The > first couple of comments below are about it. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/collectedHeap.cpp > 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { > ... > 338 // please not mismatch between size (in 32/64 bit words), and ju_addr that always point to a 32 bit word > > s/not/note/ > > Also, the assert on 340 looks indented 3 rather than 2. Will fix both. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/collectedHeap.cpp > 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { > >> Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, >> it was buggy before (but never called), It is now called (and hopefully >> correct). > > I don't understand "but never called" as it looks like it has been > called all along from MemAllocator::allocate_outside_tlab. Except > that's only when UseTLAB is false, and it always defaults true if any > of C1, C2, or JVMCI are included. We do have some -UseTLAB tests > though, and they aren't all with CMS, so I'm not sure how a problem > here hasn't already appeared. > > Because I don't understand "but never called" I'm failing to > understand how this hasn't shown up as a problem before. Seems like it > should never have worked and there would be test failures at least. > Sorry, I was sloppy in my description, it has not been called from our /test suite/. Special command line option (CheckMemoryInitialization && ZapUnusedHeapArea) needs to be given to the JVM for the check to be done. -XX:+CheckMemoryInitialization is only used in one test that hard codes serial gc. That -XX:+CheckMemoryInitialization flag looks quite unused might be a problem in itself, I do not know. > Part of the problem here is that Copy::fill_to_words takes a juint > fill value that it duplicates in high/low on 64bit platforms. That > seems wrong; shouldn't it take a platform-word sized value and just > store that? But making any such change is going to require some care. > > And it results in the CollectedHeap implementation's use of intptr_t > on 64bit platforms comparing badHeapWord (a juint, so 32bits) with > 64bit (((julong)badHeapWord << 32) | badHeapWord). So how did this > ever manage to pass testing? > > However, on a 64bit platform the new code (and the old > GenCollectedHeap code) is only checking every other 32bit value. The > step distance is 8 bytes but the value read at each step is only 4 > bytes. The old code did not work, but what is wrong with the new code? ++ju_addr increments /four/ bytes at a time (ju_addr is a pointer to uint32_t), and (if I am not mistaken) the full memory range is checked as the sum of reinterpret_cast(addr + size) is done in words (not juints) and /then/ casted to juint*. Or did I miss something? > > There is also a (pre-existing) !PRODUCT vs ASSERT mismatch here. The > checker is !PRODUCT, but the filling is debug-only (see > SpaceMangler::mangle_region). So I think it's still broken in > "optimized" builds. (It is periodically suggested that we get rid of > that configuration (JDK-8183287, for example) but there's always been > some folks who really want to keep it.) I have filed a bug: https://bugs.openjdk.java.net/browse/JDK-8232792 > ------------------------------------------------------------------------------ > src/hotspot/cpu/arm/globals_arm.hpp > 66 // GC Ergo Flags > > I think that comment only applied to the now removed CMSYoungGenPerWorker. > It now _appears_ to apply to TypeProfileLevel, which isn't a GC flag. > Suggest just removing the comment. > > Similarly in (all?) the other globals_.hpp files: > src/hotspot/cpu/aarch64/globals_aarch64.hpp > src/hotspot/cpu/ppc/globals_ppc.hpp > src/hotspot/cpu/s390/globals_s390.hpp > src/hotspot/cpu/sparc/globals_sparc.hpp > src/hotspot/cpu/x86/globals_x86.hpp > src/hotspot/cpu/zero/globals_zero.hpp > Will fix. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp > 301 * in the nursery, this would happen for humongous objects. This is similar to > 302 * how CMS was required to handle this case, see the comments for the method > 303 * CollectedHeap::new_deferred_store_barrier and OptoRuntime::new_deferred_store_barrier. > > I would prefer this didn't mention CMS at all anymore, e.g. drop the > phase "This is similar to how CMS was required to handle this case". Will fix. > > But while exploring this I discovered that the functions being > referred to here no longer exist, at least not by that name. That is, > there are no occurrences of "new_deferred_store_barrier" other than in > some comments. I haven't tried to figure out what's happened beyond > noticing that... > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/parallel/psPromotionManager.hpp > 105 // need to scan; this is basically how ParNew did partial array > 106 // scanning too). To be able to distinguish between reference > > I would prefer this didn't mention ParNew at all anymore, e.g. drop > everything after the semicolon. Will fix. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/blockOffsetTable.hpp > 44 // - BlockOffsetArrayNonContigSpace > > Doesn't exist anymore. > Will fix. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/cardTableBarrierSet.cpp > 117 // but, like in CMS, because of the presence of concurrent refinement > 118 // (much like CMS' precleaning), must strictly follow the oop-store. > 119 // Thus, using the same protocol for maintaining the intended > 120 // invariants turns out, serendepitously, to be the same for both > 121 // G1 and CMS. > > I'd prefer this didn't mention CMS anymore, e.g. > > s/, like in CMS,// > s/(much like CMS' precleaning)// > s/Thus, ...// Will fix. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp > 68 // As ConcGCThreads should be smaller than ParallelGCThreads, > 69 // we need constraint function. > 70 JVMFlag::Error ConcGCThreadsConstraintFunc(uint value, bool verbose) { > 71 // G1 GC use ConcGCThreads. > 72 if (GCConfig::is_gc_selected(CollectedHeap::G1) && (value > ParallelGCThreads)) { > > Other collectors (Shenandoah and Z) also use ConcGCThreads. I don't > know if ConcGCThreads is supposed to be not greater than > ParallelGCThreads for those collectors. It might be a bug that this > code was checking for specific GCs here (formerly G1 and CMS, now just > G1). (I _think_ this code might pre-date both Shenandoah and Z, at > least in open code.) > > There are some other constraint functions that are checking for > specific GCs that maybe ought not to be. > > Looking into this and doing any further changes should be deferred to > a separate RFE rather than trying to include in this CMS removal > change. I have filed: https://bugs.openjdk.java.net/browse/JDK-8232794 > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/referenceProcessor.hpp > 220 // of an oop. It is currently initialized to NULL for all > 221 // collectors except for G1. > > It might be better to leave out the last sentence. Shenandoah uses > _is_alive_non_header too, though initialized to NULL and manipulated > where needed using ReferenceProcessorIsAliveMutator. Will fix. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markWord.hpp > 130 static const int unused_gap_bits = LP64_ONLY(1) NOT_LP64(0); > ... > 138 static const int unused_gap_shift = age_shift + age_bits; > 139 static const int hash_shift = unused_gap_shift + unused_gap_bits; > > For this change, I completely agree with this renaming of CMS bits to > "unused_gap". Moving header bits around seems likely to have lots of > "interesting" effects. I assume there will be a followup RFE to clean > this up? I have filed: https://bugs.openjdk.java.net/browse/JDK-8232795 > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/arguments.cpp > > 73 product options bite the dust! :-) > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/arguments.cpp > 4177 // Non NUMA-aware collectors such as G1 and Serial-GC on > > FYI, there will be a minor merge conflict here between you and > Sangheon's G1 NUMA changes. OK > > ------------------------------------------------------------------------------ > > I only skimmed the Serviceability Agent changes. They look ok, but > I'm not very familiar with that code, so don't count me as having > reviewed that part. > > ------------------------------------------------------------------------------ > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java > > 234 Parallel(true, "UseParallelGC", "UseParallelOldGC"), > > You removed UseParNewGC from here. Seems like that use was just > wrong. -XX:+UseParNewGC alone was ParNew + SerialOld (so nothing to > do with "ParallelGC"), and that combination and usage was deprecated > in JDK 8 (JEP 173) and removed in JDK 9 (JEP 214). The UseParNewGC > doesn't even exist anymore. > > So good find! Could have been a separate bug, but doesn't seem worth > the effort now. Agree that it is not worth the effort, it is also related to removal of ParNew in CMS (even though the "Use" flag was removed prior to this). > ------------------------------------------------------------------------------ > test/hotspot/jtreg/runtime/7167069/PrintAsFlag.java > > Removal of -XX:CMSSmallCoalSurplusPercent=1.05 leaves no floating > point flags in the command, so that case is no longer covered. > > ------------------------------------------------------------------------------ > test/hotspot/jtreg/runtime/testlibrary/ClassUnloadCommon.java > 65 allocateMemory(16 * 1024); // yg size is 8m with cms[[keep?]], force young collection > > This looks like a lingering TODO for this change. Yes, I thought I forgot one, but could not find it, thanks! > > ------------------------------------------------------------------------------ > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/TestDriver.java > > 48 * is enabled and G1 is enbled. If ExplicitGCInvokesConcurrent and > 49 * G1 is enbled the test searches for 'GC' string in output. > > [pre-existing, but since you are touching these lines anyway...] > > s/enbled/enabled/ -- two occurrences Will fix. > > [and another pre-existing problem nearby] > This line: > 47 * searched for 'Full GC' string, unless ExplicitGCInvokesConcurrent > > doesn't match the code here: > 86 keyPhrase = "Pause Full"; Will fix. > > ------------------------------------------------------------------------------ > test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java > Removed: > 28 * @comment Graal does not support CMS > 29 * @requires !vm.graal.enabled > > This @requires was disabling this test for all collectors when graal > was enabled, not just for CMS. Has this been run with graal and all > other GCs? What I tried to do was replacing CMS with G1 in this test as both are setting MaxNewSize. G1 is working with graal, right? I have not run all test configurations, but tier 1-5 did work. If I understand, this test case will not run with any GC other than G1 as it is hard coded as an argument to the process builder. > > ------------------------------------------------------------------------------ > test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java > 66 "-XX:+UseConcMarkSweepGC", // this will cause MaxNewSize to be FLAG_SET_ERGO > => > 64 "-XX:+UseConcG1GC", // this will cause MaxNewSize to be FLAG_SET_ERGO > > Seems like this should be using +UseG1GC. (Not relying on this bogus > option being ignored and defaulting to G1, and not having anything to > do with the comment.) Yes! Bad from my side, embarrassing, will fix. G1 sets the same MaxNewSize so the comment is still correct, and the flag is checked later in the test case: checkOrigin("MaxNewSize", Origin.ERGONOMIC); I just removed "Conc" part that I failed to write over. Is that okay? > > ------------------------------------------------------------------------------ > test/jdk/java/lang/management/MemoryMXBean/PendingAllGC.sh > > Maybe this test should be updated to test with other collectors than > just the default (now G1) and Parallel. File an RFE? Okay: https://bugs.openjdk.java.net/browse/JDK-8232798 > > ------------------------------------------------------------------------------ > test/jdk/jdk/jfr/event/gc/collection/GCEventAll.java > 243 if (GCHelper.gcG1Old.equals(oldCollector)) { > 244 // ConcurrentMarkSweep mixes old and new collections. Not same values as in MXBean. > 245 // MXBean does not report old collections for G1Old, so we have nothing to compare with. > 246 return; > 247 } > > Comment also needed to be updated. > I removed the comment line: // ConcurrentMarkSweep mixes old and new collections. Not same values as in MXBean. > ------------------------------------------------------------------------------ > test/jdk/jdk/jfr/event/oldobject/TestMetadataRetention.java > 90 // System.gc() will trigger class unloading if -XX:+ExplicitGCInvokesConcurrent > 91 // is NOT set. If this flag is set G1 will never unload classes on System.gc(). > > I think this comment is no longer true. > > If this test doesn't work with -ExplicitGCInvokesConcurrent then that > should be filtered in an @requires check. I don't know if it doesn't > work though. > > I don't know what this part of the comment means though: > 92 // As far as the "jfr" key guarantees no VM flags are set from the > 93 // outside it should be enough with System.gc(). > I assume it's referring to the "@key jfr" line in the @test description. > But I don't know what that does. > > Similarly in these: > test/jdk/jdk/jfr/event/runtime/TestClassLoadingStatisticsEvent.java > test/jdk/jdk/jfr/event/runtime/TestClassUnloadEvent.java I guess this will be handled by: https://bugs.openjdk.java.net/browse/JDK-8232244 > ------------------------------------------------------------------------------ > Thanks for looking through all of this! /Leo From leo.korinth at oracle.com Tue Oct 22 16:09:50 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 22 Oct 2019 18:09:50 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: On 21/10/2019 20:08, coleen.phillimore at oracle.com wrote: > > > On 10/18/19 4:20 AM, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that would >> be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to >> remove all traces of CMS. I guess there are much more to cleanup, and >> suggestions of more to remove are welcomed. I think more complicated >> cleanups should be dealt with in separate enhancements. > > I can send you a list of things extra things I know about.? Thank you > for not addressing all of the CMS special cases with this patch. > > http://cr.openjdk.java.net/~lkorinth/8232365/00/src/hotspot/share/oops/oop.inline.hpp.udiff.html > > > This set_klass_to_list_ptr was an especially aggregious type violation. > Since you've touched this, can you remove these functions with your patch: > > ? // For when the klass pointer is being used as a linked list "next" > field. > ? inline void set_klass_to_list_ptr(oop k); > ? inline oop list_ptr_from_klass(); I will remove them, Thanks! /Leo > > The runtime and oops changes look good. > Coleen > > > >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should >> be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ? tier 1-5. >> >> Thanks, >> Leo > From erik.joelsson at oracle.com Tue Oct 22 16:11:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 09:11:06 -0700 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <28c2db67-bdd4-b8b0-7ac3-29fcde6d66e1@oracle.com> Looks good. /Erik On 2019-10-22 00:17, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings. Some of > them, but not all, can be individually enabled or disabled. All other > libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra triggers a couple of warnings that can be > individually disabled. (The idea here is not to just permanently > disable those warnings (unless that makes sense), but to look at these > warnings one at a time and see how they can be addressed.) > > My trial runs with -Wextra has already found a couple of real issues > (fixed in JDK-8213414). > > I have tested that this compiles without warnings on gcc 4.8, 5.5, > 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, > aarch64 and arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > > /Magnus From leo.korinth at oracle.com Tue Oct 22 16:30:06 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 22 Oct 2019 18:30:06 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <94194567-430c-97df-2e96-fe895123311a@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> <94194567-430c-97df-2e96-fe895123311a@oracle.com> Message-ID: <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> Hi! I will add "cmsgc" like so: DEPRECATED_JVM_FEATURES="trace cmsgc" Should I file a reminder bug for later removal of that feature (I guess not)? If I should, at what version should it be removed? Thanks for finding this! /Leo On 21/10/2019 17:45, Erik Joelsson wrote: > On 2019-10-21 02:46, Magnus Ihse Bursie wrote: >> On 2019-10-21 09:43, Per Liden wrote: >>> Hi Erik, >>> >>> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>>> Hello Leo, >>>> >>>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>>> here means removed here, but configure will still accept the >>>> argument (with a warning). >>> >>> Are we really treating the list of JVM feature as a public/stable >>> API, or is there some other reason for this? Would the plan be to >>> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? >> >> Note that this is an issue for building only. A feature listed as >> deprecated in the build will not propagate outside the build system. >> >> We are basically treating the configure command line arguments as a >> "stable API". The intention is that a command line on a build script >> should not cause a build failure due to an unknown argument. We have >> traditionally had 2-3 major releases before removing deprecated >> command line options. >> > We (or at least I) have been a bit lazy with removing the deprecated > args. I wouldn't mind being a bit more aggressive. > > /Erik > > From vladimir.kozlov at oracle.com Tue Oct 22 16:38:42 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Oct 2019 09:38:42 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <6b0b5b46-a5af-adc2-4119-7991f76d2350@oracle.com> HotSpot changes seem fine to me. Thanks, Vladimir On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark > From erik.joelsson at oracle.com Tue Oct 22 16:44:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Oct 2019 09:44:04 -0700 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> References: <524345c4-0aac-4b81-7f18-26b899a28289@oracle.com> <56c87df1-8319-15eb-856c-ba81763cf5d0@oracle.com> <5a1b2bbb-b852-fd69-46c4-fac3f3b46624@oracle.com> <94194567-430c-97df-2e96-fe895123311a@oracle.com> <0f7294d8-4d8c-348d-37c6-2a5f5a32f26d@oracle.com> Message-ID: On 2019-10-22 09:30, Leo Korinth wrote: > Hi! > > I will add "cmsgc" like so: DEPRECATED_JVM_FEATURES="trace cmsgc" > Yes, exactly. Thanks! > Should I file a reminder bug for later removal of that feature (I > guess not)? If I should, at what version should it be removed? > > Thanks for finding this! > No need for a bug. We do these in bulk. /Erik > /Leo > > > On 21/10/2019 17:45, Erik Joelsson wrote: >> On 2019-10-21 02:46, Magnus Ihse Bursie wrote: >>> On 2019-10-21 09:43, Per Liden wrote: >>>> Hi Erik, >>>> >>>> On 10/18/19 2:54 PM, Erik Joelsson wrote: >>>>> Hello Leo, >>>>> >>>>> When removing a JVM feature from the VALID_JVM_FEATURES list, it >>>>> needs to be added to the DEPRECATED_JVM_FEATURES list. Deprecated >>>>> here means removed here, but configure will still accept the >>>>> argument (with a warning). >>>> >>>> Are we really treating the list of JVM feature as a public/stable >>>> API, or is there some other reason for this? Would the plan be to >>>> remove it from the DEPRECATED_JVM_FEATURES in JDK 15? >>> >>> Note that this is an issue for building only. A feature listed as >>> deprecated in the build will not propagate outside the build system. >>> >>> We are basically treating the configure command line arguments as a >>> "stable API". The intention is that a command line on a build script >>> should not cause a build failure due to an unknown argument. We have >>> traditionally had 2-3 major releases before removing deprecated >>> command line options. >>> >> We (or at least I) have been a bit lazy with removing the deprecated >> args. I wouldn't mind being a bit more aggressive. >> >> /Erik >> >> From bob.vandette at oracle.com Tue Oct 22 17:31:55 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 13:31:55 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); This will require some minor changes to jvmFlags.hpp 34 struct JVMFlag { 35 enum Flags { 36 // latest value origin 37 DEFAULT = 0, 38 COMMAND_LINE = 1, 39 ENVIRON_VAR = 2, 40 CONFIG_FILE = 3, 41 MANAGEMENT = 4, 42 ERGONOMIC = 5, 43 ATTACH_ON_DEMAND = 6, 44 INTERNAL = 7, + 45 RESOURCE = 8, 46 - 47 LAST_VALUE_ORIGIN = INTERNAL, + 47 LAST_VALUE_ORIGIN = RESOURCE, Bob. > On Oct 21, 2019, at 11:22 PM, mark.reinhold at oracle.com wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > This change implements jlink plugins, and associated changes in the VM > and libraries, to support the following new jlink options: > > - --vendor-bug-url= overrides the vendor bug URL baked > into the build. The value of the system property "java.vendor.url.bug" > will be . > > - --vendor-vm-bug-url= overrides the vendor VM bug > URL baked into the build. This value will be displayed in VM error > logs. > > - --vendor-version= overrides the vendor version string > baked into the build, if any. The value of the system property > "java.vendor.version" will be . This value will be > displayed in the output of java --version. > > - --add-options= prepends the specified string, > which may include whitespace, before any other options when invoking > the VM in the resulting image. > > The vendor-information plugins work by using the JDK?s internal ASM > library to redefine static fields in the java.lang.VersionProps class. > The VM reads the vendor-version and vendor-vm-bug-url strings from that > class during startup. > > The add-options plugin works by storing the requested options in an > internal resource, /java.base/jdk/internal/vm/options. The VM loads that > resource from the lib/modules jimage file during startup and prepends any > options found there to those given on the command line. > > Passes tier1-3 and JCK on {linux,macos,windows}-x64. > > Thanks, > - Mark From mark.reinhold at oracle.com Tue Oct 22 19:22:32 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 12:22:32 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022122232.395077958@eggemoggin.niobe.net> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: > In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? > > - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); > + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); > > This will require some minor changes to jvmFlags.hpp > > 34 struct JVMFlag { > 35 enum Flags { > 36 // latest value origin > 37 DEFAULT = 0, > 38 COMMAND_LINE = 1, > 39 ENVIRON_VAR = 2, > 40 CONFIG_FILE = 3, > 41 MANAGEMENT = 4, > 42 ERGONOMIC = 5, > 43 ATTACH_ON_DEMAND = 6, > 44 INTERNAL = 7, > > + 45 RESOURCE = 8, > > 46 > > - 47 LAST_VALUE_ORIGIN = INTERNAL, > + 47 LAST_VALUE_ORIGIN = RESOURCE, Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin to handle the RESOURCE case (which is easy). Is ?RESOURCE? the best name here? Sounds awfully generic. How about ?JIMAGE? or ?JIMAGE_RESOURCE?? - Mark From mark.reinhold at oracle.com Tue Oct 22 19:25:17 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 12:25:17 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022122517.305808697@eggemoggin.niobe.net> 2019/10/22 7:15:10 -0700, alan.bateman at oracle.com: > On 22/10/2019 04:22, mark.reinhold at oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > I've read through the code for the new jlink plugins and the changes to > VersionProps and it looks good. > > An alternative for VersionProps would have been to generate a helper > class at link time rather than extending the static initilizer to set > the fields. That would allow the VENDOR* fields to be final (but I don't > think it makes too much difference and it may be a bit more complicated > due to having 4 plugins contributing code). Yes, that would?ve been more complex, and the finality of these fields isn?t critical. > The need for a plugin per CLI option may be motivation to explore (in > the future) having a single plugin expose multiple options. Agreed. Thanks, - Mark From kim.barrett at oracle.com Tue Oct 22 19:37:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Oct 2019 15:37:57 -0400 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <1c57c422-2b29-d5e7-ac72-17cbaedd073a@oracle.com> References: <1c57c422-2b29-d5e7-ac72-17cbaedd073a@oracle.com> Message-ID: > On Oct 22, 2019, at 11:17 AM, Leo Korinth wrote: > > On 21/10/2019 23:48, Kim Barrett wrote: >>> On Oct 18, 2019, at 4:20 AM, Leo Korinth wrote: >> src/hotspot/share/gc/shared/collectedHeap.cpp >> 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { >>> Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, >>> it was buggy before (but never called), It is now called (and hopefully >>> correct). >> I don't understand "but never called" as it looks like it has been >> called all along from MemAllocator::allocate_outside_tlab. Except >> that's only when UseTLAB is false, and it always defaults true if any >> of C1, C2, or JVMCI are included. We do have some -UseTLAB tests >> though, and they aren't all with CMS, so I'm not sure how a problem >> here hasn't already appeared. > >> Because I don't understand "but never called" I'm failing to >> understand how this hasn't shown up as a problem before. Seems like it >> should never have worked and there would be test failures at least. > > Sorry, I was sloppy in my description, it has not been called from our /test suite/. Special command line option (CheckMemoryInitialization && ZapUnusedHeapArea) needs to be given to the JVM for the check to be done. -XX:+CheckMemoryInitialization is only used in one test that hard codes serial gc. That -XX:+CheckMemoryInitialization flag looks quite unused might be a problem in itself, I do not know. Thanks for the explanation. I'd overlooked CheckMemoryInitialization. That actually seems like a reasonable use of a develop/debug option. Seems like there should be more tests though :) Another RFE for you to file... >> Part of the problem here is that Copy::fill_to_words takes a juint >> fill value that it duplicates in high/low on 64bit platforms. That >> seems wrong; shouldn't it take a platform-word sized value and just >> store that? But making any such change is going to require some care. >> And it results in the CollectedHeap implementation's use of intptr_t >> on 64bit platforms comparing badHeapWord (a juint, so 32bits) with >> 64bit (((julong)badHeapWord << 32) | badHeapWord). So how did this >> ever manage to pass testing? >> However, on a 64bit platform the new code (and the old >> GenCollectedHeap code) is only checking every other 32bit value. The >> step distance is 8 bytes but the value read at each step is only 4 >> bytes. > > The old code did not work, but what is wrong with the new code? ++ju_addr increments /four/ bytes at a time (ju_addr is a pointer to uint32_t), and (if I am not mistaken) the full memory range is checked as the sum of reinterpret_cast(addr + size) is done in words (not juints) and /then/ casted to juint*. > > Or did I miss something? Sorry about that; you are correct. I got confused by the fill_to_words weirdness and how it interacts here. From bob.vandette at oracle.com Tue Oct 22 19:43:42 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 15:43:42 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022122232.395077958@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> Message-ID: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> > On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >> In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? >> >> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >> >> This will require some minor changes to jvmFlags.hpp >> >> 34 struct JVMFlag { >> 35 enum Flags { >> 36 // latest value origin >> 37 DEFAULT = 0, >> 38 COMMAND_LINE = 1, >> 39 ENVIRON_VAR = 2, >> 40 CONFIG_FILE = 3, >> 41 MANAGEMENT = 4, >> 42 ERGONOMIC = 5, >> 43 ATTACH_ON_DEMAND = 6, >> 44 INTERNAL = 7, >> >> + 45 RESOURCE = 8, >> >> 46 >> >> - 47 LAST_VALUE_ORIGIN = INTERNAL, >> + 47 LAST_VALUE_ORIGIN = RESOURCE, > > Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin > to handle the RESOURCE case (which is easy). > > Is ?RESOURCE? the best name here? Sounds awfully generic. How about > ?JIMAGE? or ?JIMAGE_RESOURCE?? JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. Bob. > > - Mark From kim.barrett at oracle.com Tue Oct 22 20:25:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Oct 2019 16:25:17 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> Message-ID: <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> > On Oct 22, 2019, at 3:17 AM, Magnus Ihse Bursie wrote: > > I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 Change looks good. I remain somewhat leary of omnibus warning options in a code base like this, which is large and needs to support multiple compiler versions on multiple platforms. But at least most can be disabled if needed. Note that gcc9 adds: -Wdeprecated-copy Warn that the implicit declaration of a copy constructor or copy assignment operator is deprecated if the class has a user-provided copy constructor or copy assignment operator, in C++11 and up. This warning is enabled by -Wextra. With -Wdeprecated-copy-dtor, also deprecate if the class has a user-provided destructor. -Wredundant-move This warning warns about redundant calls to std::move; that is, when a move operation would have been performed even without the std::move call. Neither of these are an issue for us yet, because we're not yet using C++11 or later. But I expect -Wdeprecated-copy to cause problems for that update, and we might need to (temporarily) globally disable it as part of JEP 347. It's annoying that some of its warnings have no associated -Wno-xxx, in particular the one about mixing integral types and enum types in conditional expressions, because of the history of our code base and because it's perfectly well-formed usage. But apparently we don't have any of those right now. > On Oct 22, 2019, at 4:28 AM, Magnus Ihse Bursie wrote: > I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. This depends on what you mean by additions or changes to -Wextra. As mentioned above, gcc9 adds two new warnings, but they can be individually controlled. The set of warnings only provided by -Wextra and not individually controlled has indeed not changed in a long time. I checked, and gcc4.9 and gcc9.2 have the same set of those. From mandy.chung at oracle.com Tue Oct 22 21:12:18 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2019 14:12:18 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191021202253.825695282@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: > RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 > Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > Looks good to me.? One minor comment: AddResourcePlugin isn't really a FILTER, probably best to add a new category for new resource file.?? jlink hardcodes the order of the categories that determines the order of the plugins to be executed (I see the existing implementation could be cleaned up in the future). ? I think we didn't want to the options resource to be filtered by --exclude-resources plugin and so the add-options plugin should run after all filter plugins. Mandy From mark.reinhold at oracle.com Tue Oct 22 22:36:28 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 15:36:28 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> Message-ID: <20191022153628.417897318@eggemoggin.niobe.net> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>> In arguments.cpp, could you use a new JVMFlag to declare options >>> that came from this resource as RESOURCE? >>> >>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>> >>> This will require some minor changes to jvmFlags.hpp >>> >>> ... >> >> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >> to handle the RESOURCE case (which is easy). >> >> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >> ?JIMAGE? or ?JIMAGE_RESOURCE?? > > JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. JIMAGE_RESOURCE it is, then. Relative patch below; original webrev updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). - Mark ---- # HG changeset patch # Parent efca1844245ad7351418ef41efc86c5055ac3edf Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp --- a/src/hotspot/share/runtime/arguments.cpp +++ b/src/hotspot/share/runtime/arguments.cpp @@ -2203,7 +2203,7 @@ set_mode_flags(_mixed); // Parse args structure generated from java.base vm options resource - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); if (result != JNI_OK) { return result; } diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp @@ -697,6 +697,8 @@ st->print("attach"); break; case INTERNAL: st->print("internal"); break; + case JIMAGE_RESOURCE: + st->print("jimage"); break; } st->print("}"); } diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp @@ -44,8 +44,9 @@ ERGONOMIC = 5, ATTACH_ON_DEMAND = 6, INTERNAL = 7, + JIMAGE_RESOURCE = 8, - LAST_VALUE_ORIGIN = INTERNAL, + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, VALUE_ORIGIN_BITS = 4, VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), From mark.reinhold at oracle.com Tue Oct 22 22:37:38 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 22 Oct 2019 15:37:38 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> Message-ID: <20191022153738.224816243@eggemoggin.niobe.net> 2019/10/22 14:12:18 -0700, mandy.chung at oracle.com: > On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > Looks good to me. One minor comment: > > AddResourcePlugin isn't really a FILTER, probably best to add a new > category for new resource file. jlink hardcodes the order of the > categories that determines the order of the plugins to be executed (I > see the existing implementation could be cleaned up in the future). I > think we didn't want to the options resource to be filtered by > --exclude-resources plugin and so the add-options plugin should run > after all filter plugins. Good point -- that makes sense. Relative patch below; original webrev updated in place. Thanks, - Mark ---- # HG changeset patch # Parent 43f160bda3c7a2a7009df91afa37469760d42333 Addendum 2 (jlink ADDER): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java @@ -50,6 +50,7 @@ static { CATEGORIES_ORDER.add(Category.FILTER); + CATEGORIES_ORDER.add(Category.ADDER); CATEGORIES_ORDER.add(Category.TRANSFORMER); CATEGORIES_ORDER.add(Category.MODULEINFO_TRANSFORMER); CATEGORIES_ORDER.add(Category.SORTER); diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java @@ -58,7 +58,7 @@ @Override public Category getType() { - return Category.FILTER; + return Category.ADDER; } @Override diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java @@ -39,6 +39,7 @@ * Order of categories matches the plugin sort order. *
    *
  1. FILTER: Filter in/out resources or files.
  2. + *
  3. ADDER: Add resources or files.
  4. *
  5. TRANSFORMER: Transform resources or files(eg: refactoring, bytecode * manipulation).
  6. *
  7. MODULEINFO_TRANSFORMER: Transform only module-info.class
  8. @@ -52,6 +53,7 @@ */ public enum Category { FILTER("FILTER"), + ADDER("ADDER"), TRANSFORMER("TRANSFORMER"), MODULEINFO_TRANSFORMER("MODULEINFO_TRANSFORMER"), SORTER("SORTER"), From bob.vandette at oracle.com Tue Oct 22 22:42:51 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 22 Oct 2019 18:42:51 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> Message-ID: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> Hotspot changes look good to me. Bob. > On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>> that came from this resource as RESOURCE? >>>> >>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>> >>>> This will require some minor changes to jvmFlags.hpp >>>> >>>> ... >>> >>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>> to handle the RESOURCE case (which is easy). >>> >>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >> >> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. > > JIMAGE_RESOURCE it is, then. Relative patch below; original webrev > updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). > > - Mark > > > ---- > > # HG changeset patch > # Parent efca1844245ad7351418ef41efc86c5055ac3edf > Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options > > diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp > --- a/src/hotspot/share/runtime/arguments.cpp > +++ b/src/hotspot/share/runtime/arguments.cpp > @@ -2203,7 +2203,7 @@ > set_mode_flags(_mixed); > > // Parse args structure generated from java.base vm options resource > - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); > + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); > if (result != JNI_OK) { > return result; > } > diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp > --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp > +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp > @@ -697,6 +697,8 @@ > st->print("attach"); break; > case INTERNAL: > st->print("internal"); break; > + case JIMAGE_RESOURCE: > + st->print("jimage"); break; > } > st->print("}"); > } > diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp > --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp > +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp > @@ -44,8 +44,9 @@ > ERGONOMIC = 5, > ATTACH_ON_DEMAND = 6, > INTERNAL = 7, > + JIMAGE_RESOURCE = 8, > > - LAST_VALUE_ORIGIN = INTERNAL, > + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, > VALUE_ORIGIN_BITS = 4, > VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), > From vladimir.kozlov at oracle.com Tue Oct 22 22:44:55 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Oct 2019 15:44:55 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <024C3710-D24D-40B0-A21F-E7947D09A07E@oracle.com> Message-ID: <8B9D1BE8-531E-433A-AC6B-FE8088AD11C2@oracle.com> +1 Thanks Vladimir > On Oct 22, 2019, at 3:42 PM, Bob Vandette wrote: > > Hotspot changes look good to me. > > Bob. > > >> On Oct 22, 2019, at 6:36 PM, mark.reinhold at oracle.com wrote: >> >> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>>> that came from this resource as RESOURCE? >>>>> >>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>>> >>>>> This will require some minor changes to jvmFlags.hpp >>>>> >>>>> ... >>>> >>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>>> to handle the RESOURCE case (which is easy). >>>> >>>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >>> >>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. >> >> JIMAGE_RESOURCE it is, then. Relative patch below; original webrev >> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). >> >> - Mark >> >> >> ---- >> >> # HG changeset patch >> # Parent efca1844245ad7351418ef41efc86c5055ac3edf >> Addendum 1 (JVMFlags): 8232080: jlink plugins for vendor information and run-time options >> >> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp >> --- a/src/hotspot/share/runtime/arguments.cpp >> +++ b/src/hotspot/share/runtime/arguments.cpp >> @@ -2203,7 +2203,7 @@ >> set_mode_flags(_mixed); >> >> // Parse args structure generated from java.base vm options resource >> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::JIMAGE_RESOURCE); >> if (result != JNI_OK) { >> return result; >> } >> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.cpp b/src/hotspot/share/runtime/flags/jvmFlag.cpp >> --- a/src/hotspot/share/runtime/flags/jvmFlag.cpp >> +++ b/src/hotspot/share/runtime/flags/jvmFlag.cpp >> @@ -697,6 +697,8 @@ >> st->print("attach"); break; >> case INTERNAL: >> st->print("internal"); break; >> + case JIMAGE_RESOURCE: >> + st->print("jimage"); break; >> } >> st->print("}"); >> } >> diff --git a/src/hotspot/share/runtime/flags/jvmFlag.hpp b/src/hotspot/share/runtime/flags/jvmFlag.hpp >> --- a/src/hotspot/share/runtime/flags/jvmFlag.hpp >> +++ b/src/hotspot/share/runtime/flags/jvmFlag.hpp >> @@ -44,8 +44,9 @@ >> ERGONOMIC = 5, >> ATTACH_ON_DEMAND = 6, >> INTERNAL = 7, >> + JIMAGE_RESOURCE = 8, >> >> - LAST_VALUE_ORIGIN = INTERNAL, >> + LAST_VALUE_ORIGIN = JIMAGE_RESOURCE, >> VALUE_ORIGIN_BITS = 4, >> VALUE_ORIGIN_MASK = right_n_bits(VALUE_ORIGIN_BITS), >> > From mandy.chung at oracle.com Tue Oct 22 23:30:52 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2019 16:30:52 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153738.224816243@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022153738.224816243@eggemoggin.niobe.net> Message-ID: <1934b0f7-10a9-7374-a479-31087363db75@oracle.com> On 10/22/19 3:37 PM, mark.reinhold at oracle.com wrote: > 2019/10/22 14:12:18 -0700, mandy.chung at oracle.com: >> On 10/21/19 8:22 PM, mark.reinhold at oracle.com wrote: >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ >> Looks good to me. One minor comment: >> >> AddResourcePlugin isn't really a FILTER, probably best to add a new >> category for new resource file. jlink hardcodes the order of the >> categories that determines the order of the plugins to be executed (I >> see the existing implementation could be cleaned up in the future). I >> think we didn't want to the options resource to be filtered by >> --exclude-resources plugin and so the add-options plugin should run >> after all filter plugins. > Good point -- that makes sense. > > Relative patch below; original webrev updated in place. Looks good. Mandy From magnus.ihse.bursie at oracle.com Wed Oct 23 08:06:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Oct 2019 10:06:53 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> References: <278d03b1-7412-eaa2-5ee8-c75ccf31e494@oracle.com> <15D893D4-F940-47A8-AB8B-49DD8DC3B006@oracle.com> Message-ID: <6e1a5bff-349c-0605-fdff-284ec9a44ff6@oracle.com> On 2019-10-22 22:25, Kim Barrett wrote: >> On Oct 22, 2019, at 3:17 AM, Magnus Ihse Bursie wrote: >> >> I have tested that this compiles without warnings on gcc 4.8, 5.5, 6.5, 7.4 and 8.3 on x64. I have also tried building zero on x64, aarch64 and arm32 with gcc 8.3. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-enable-extra-on-hotspot/webrev.01 > Change looks good. Thanks. > > I remain somewhat leary of omnibus warning options in a code base like > this, which is large and needs to support multiple compiler versions > on multiple platforms. But at least most can be disabled if needed. It's a three-edged sword. I like the concept of saying to the compiler "Here's my code, give it your best shot to find issues with it", and then explicitly telling it "well, no, that's not really a problem, ignore it". And if we really had to specify *each and every* warnings that a compiler should check for, the command lines would be excruciatingly long. On the other hand, if the set of warnings change between compiler versions, we have a harder time keeping the code warning free. Once again, if the warnings are reasonable, fixing issues is a good thing (and they could even have been avoided by writing good code in the first place :-)). But sometimes they are over-zealous and it is just an annoyance to fix. But then again, even for an individual, specified warning, the conditions for when and how it applies can change between compiler versions, so the same situation is really always present, even if it's on a "less likely" scale. > > Note that gcc9 adds: > -Wdeprecated-copy > Warn that the implicit declaration of a copy constructor or copy > assignment operator is deprecated if the class has a user-provided > copy constructor or copy assignment operator, in C++11 and up. This > warning is enabled by -Wextra. With -Wdeprecated-copy-dtor, also > deprecate if the class has a user-provided destructor. > > -Wredundant-move > This warning warns about redundant calls to std::move; that is, when a > move operation would have been performed even without the std::move > call. > > Neither of these are an issue for us yet, because we're not yet using > C++11 or later. But I expect -Wdeprecated-copy to cause problems for > that update, and we might need to (temporarily) globally disable it as > part of JEP 347. > > It's annoying that some of its warnings have no associated -Wno-xxx, > in particular the one about mixing integral types and enum types in > conditional expressions, because of the history of our code base and > because it's perfectly well-formed usage. But apparently we don't have > any of those right now. > >> On Oct 22, 2019, at 4:28 AM, Magnus Ihse Bursie wrote: >> I wouldn't count on gcc 9 bringing in anything new to -Wextra. In general, gcc is *extremely* conservative about changing -Wextra nowadays. Virtually all new warnings that are added are added as indivudual warnings with explicit names to be turned on or turned off. Only after a long vetting process does any of these gets added to -Wextra. I think the last time anything was added to -Wextra was in like gcc 6..? So the -Wextra is in a way a bit of a legacy system in gcc for handling warnings. > This depends on what you mean by additions or changes to -Wextra. As > mentioned above, gcc9 adds two new warnings, but they can be > individually controlled. The set of warnings only provided by -Wextra > and not individually controlled has indeed not changed in a long time. > I checked, and gcc4.9 and gcc9.2 have the same set of those. > Yes, new warnings can be individually disabled. It's a shame that not all -Wextra warnings can be, but unless we're prepared to submit a patch to gcc, I assume we're in no position to complain. :-) /Magnus From harold.seigel at oracle.com Wed Oct 23 12:39:55 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 23 Oct 2019 08:39:55 -0400 Subject: Remove support of old code attribute format In-Reply-To: <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> References: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> Message-ID: <7cb64b3b-4816-3422-e9ce-5891880a3d11@oracle.com> Hi Remy, I entered bug https://bugs.openjdk.java.net/browse/JDK-8232890 for this issue. Our plan is to remove the hotspot code that supports the undocumented Code attribute format. Thanks for pointing this out to us. Harold On 10/21/2019 7:32 PM, Remi Forax wrote: > *ping* > > ----- Mail original ----- >> De: "Remi Forax" >> ?: "hotspot-dev" >> Envoy?: Samedi 19 Octobre 2019 18:57:22 >> Objet: Remove support of old code attribute format >> Hi all, >> currently hotspot supports parsing a code attribute format [1] that is not >> described by the JVM spec if the major version is 45 and the minor <= 2. >> >> Obviously, none of the bytecode tools or other VMs support that format because >> it is not described in the JVMS (it predates Java), >> so it can be used to create classes that can not be inspected but run on >> hotspot. >> >> Someone named Chris ask us (ASM) to support that format [2], the same guy also >> asks for the support in javap see [3]. >> >> I think it's better to not change the VM spec but fix hotspot. >> >> Before logging a bug, i want to know what you guys are thinking about that. >> >> regards, >> R?mi >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/f7df2861be47/src/hotspot/share/classfile/classFileParser.cpp#l2451 >> [2] https://gitlab.ow2.org/asm/asm/issues/317888 >> [3] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8232598 From forax at univ-mlv.fr Wed Oct 23 13:28:45 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Oct 2019 15:28:45 +0200 (CEST) Subject: Remove support of old code attribute format In-Reply-To: <7cb64b3b-4816-3422-e9ce-5891880a3d11@oracle.com> References: <1261222232.2817062.1571504242912.JavaMail.zimbra@u-pem.fr> <969319352.462469.1571700774317.JavaMail.zimbra@u-pem.fr> <7cb64b3b-4816-3422-e9ce-5891880a3d11@oracle.com> Message-ID: <1474463393.1149907.1571837325401.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Harold David Seigel" > ?: "hotspot-dev" > Envoy?: Mercredi 23 Octobre 2019 14:39:55 > Objet: Re: Remove support of old code attribute format > Hi Remy, > > I entered bug https://bugs.openjdk.java.net/browse/JDK-8232890 for this > issue. > > Our plan is to remove the hotspot code that supports the undocumented > Code attribute format. > > Thanks for pointing this out to us. thanks Harold ! > > Harold R?mi > > On 10/21/2019 7:32 PM, Remi Forax wrote: >> *ping* >> >> ----- Mail original ----- >>> De: "Remi Forax" >>> ?: "hotspot-dev" >>> Envoy?: Samedi 19 Octobre 2019 18:57:22 >>> Objet: Remove support of old code attribute format >>> Hi all, >>> currently hotspot supports parsing a code attribute format [1] that is not >>> described by the JVM spec if the major version is 45 and the minor <= 2. >>> >>> Obviously, none of the bytecode tools or other VMs support that format because >>> it is not described in the JVMS (it predates Java), >>> so it can be used to create classes that can not be inspected but run on >>> hotspot. >>> >>> Someone named Chris ask us (ASM) to support that format [2], the same guy also >>> asks for the support in javap see [3]. >>> >>> I think it's better to not change the VM spec but fix hotspot. >>> >>> Before logging a bug, i want to know what you guys are thinking about that. >>> >>> regards, >>> R?mi >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/f7df2861be47/src/hotspot/share/classfile/classFileParser.cpp#l2451 >>> [2] https://gitlab.ow2.org/asm/asm/issues/317888 > >> [3] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8232598 From mark.reinhold at oracle.com Wed Oct 23 19:07:11 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Oct 2019 12:07:11 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191022153628.417897318@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> Message-ID: <20191023120711.232005374@eggemoggin.niobe.net> 2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com: > 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>> that came from this resource as RESOURCE? >>>> >>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>> >>>> This will require some minor changes to jvmFlags.hpp >>>> >>>> ... >>> >>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>> to handle the RESOURCE case (which is easy). >>> >>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >> >> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. > > JIMAGE_RESOURCE it is, then. Relative patch below; original webrev > updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). Addendum: To keep things sane for JFR and the serviceability agent, I had to propagate this change through to those subsystems. Relative patch below; original webrev updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). Okay? - Mark ---- # HG changeset patch # Parent d3f05e3b0d76e1a74a10cee180d8953d3045b6c8 Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp --- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp +++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp @@ -134,6 +134,7 @@ case JVMFlag::ERGONOMIC: return "Ergonomic"; case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand"; case JVMFlag::INTERNAL: return "Internal"; + case JVMFlag::JIMAGE_RESOURCE: return "JImage resource"; default: ShouldNotReachHere(); return ""; } } diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp --- a/src/hotspot/share/runtime/vmStructs.cpp +++ b/src/hotspot/share/runtime/vmStructs.cpp @@ -2612,6 +2612,7 @@ declare_constant(JVMFlag::ERGONOMIC) \ declare_constant(JVMFlag::ATTACH_ON_DEMAND) \ declare_constant(JVMFlag::INTERNAL) \ + declare_constant(JVMFlag::JIMAGE_RESOURCE) \ declare_constant(JVMFlag::VALUE_ORIGIN_MASK) \ declare_constant(JVMFlag::ORIG_COMMAND_LINE) diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java @@ -35,7 +35,8 @@ MANAGEMENT ("Management"), ERGONOMIC ("Ergonomic"), ATTACH_ON_DEMAND ("Attach on demand"), - INTERNAL ("Internal"); + INTERNAL ("Internal"), + JIMAGE_RESOURCE ("JImage"); private final String value; diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java @@ -114,6 +114,7 @@ public static int Flags_ERGONOMIC; public static int Flags_ATTACH_ON_DEMAND; public static int Flags_INTERNAL; + public static int Flags_JIMAGE_RESOURCE; private static int Flags_VALUE_ORIGIN_MASK; private static int Flags_ORIG_COMMAND_LINE; /** This is only present in a non-core build */ @@ -200,6 +201,8 @@ return "attach"; } else if (origin == Flags_INTERNAL) { return "internal"; + } else if (origin == Flags_JIMAGE_RESOURCE) { + return "jimage"; } else { throw new IllegalStateException( "Unknown flag origin " + origin + " is detected in " + name); @@ -484,6 +487,7 @@ Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue(); Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue(); Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue(); + Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue(); Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue(); Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue(); oopSize = db.lookupIntConstant("oopSize").intValue(); From bob.vandette at oracle.com Wed Oct 23 19:37:56 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 23 Oct 2019 15:37:56 -0400 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: <20191023120711.232005374@eggemoggin.niobe.net> References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <20191023120711.232005374@eggemoggin.niobe.net> Message-ID: > On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote: > > 2019/10/22 15:36:28 -0700, mark.reinhold at oracle.com: >> 2019/10/22 12:43:42 -0700, bob.vandette at oracle.com: >>>> On Oct 22, 2019, at 3:22 PM, mark.reinhold at oracle.com wrote: >>>> 2019/10/22 10:31:55 -0700, bob.vandette at oracle.com: >>>>> In arguments.cpp, could you use a new JVMFlag to declare options >>>>> that came from this resource as RESOURCE? >>>>> >>>>> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::INTERNAL); >>>>> + jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase, JVMFlag::RESOURCE); >>>>> >>>>> This will require some minor changes to jvmFlags.hpp >>>>> >>>>> ... >>>> >>>> Yes, that?d make sense, in which case I?d also change JVMFlag::print_origin >>>> to handle the RESOURCE case (which is easy). >>>> >>>> Is ?RESOURCE? the best name here? Sounds awfully generic. How about >>>> ?JIMAGE? or ?JIMAGE_RESOURCE?? >>> >>> JIMAGE_RESOURCE or VM_OPTIONS_RESOURCE works for me. >> >> JIMAGE_RESOURCE it is, then. Relative patch below; original webrev >> updated in place (https://cr.openjdk.java.net/~mr/rev/8232080/). > > Addendum: To keep things sane for JFR and the serviceability agent, > I had to propagate this change through to those subsystems. > > Relative patch below; original webrev updated in place > (https://cr.openjdk.java.net/~mr/rev/8232080/). > > Okay? Looks good. I?m sure you did this but I scanned the entire JDK sources and didn?t see any other uses of JVMFlag:: that would need to be updated. Bob. > > - Mark > > ---- > > # HG changeset patch > # Parent d3f05e3b0d76e1a74a10cee180d8953d3045b6c8 > Addendum 3 (propagate JIMAGE_RESOURCE): 8232080: jlink plugins for vendor information and run-time options > > diff --git a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > --- a/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > +++ b/src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp > @@ -134,6 +134,7 @@ > case JVMFlag::ERGONOMIC: return "Ergonomic"; > case JVMFlag::ATTACH_ON_DEMAND: return "Attach on demand"; > case JVMFlag::INTERNAL: return "Internal"; > + case JVMFlag::JIMAGE_RESOURCE: return "JImage resource"; > default: ShouldNotReachHere(); return ""; > } > } > diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp > --- a/src/hotspot/share/runtime/vmStructs.cpp > +++ b/src/hotspot/share/runtime/vmStructs.cpp > @@ -2612,6 +2612,7 @@ > declare_constant(JVMFlag::ERGONOMIC) \ > declare_constant(JVMFlag::ATTACH_ON_DEMAND) \ > declare_constant(JVMFlag::INTERNAL) \ > + declare_constant(JVMFlag::JIMAGE_RESOURCE) \ > declare_constant(JVMFlag::VALUE_ORIGIN_MASK) \ > declare_constant(JVMFlag::ORIG_COMMAND_LINE) > > diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java > @@ -35,7 +35,8 @@ > MANAGEMENT ("Management"), > ERGONOMIC ("Ergonomic"), > ATTACH_ON_DEMAND ("Attach on demand"), > - INTERNAL ("Internal"); > + INTERNAL ("Internal"), > + JIMAGE_RESOURCE ("JImage"); > > private final String value; > > diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > @@ -114,6 +114,7 @@ > public static int Flags_ERGONOMIC; > public static int Flags_ATTACH_ON_DEMAND; > public static int Flags_INTERNAL; > + public static int Flags_JIMAGE_RESOURCE; > private static int Flags_VALUE_ORIGIN_MASK; > private static int Flags_ORIG_COMMAND_LINE; > /** This is only present in a non-core build */ > @@ -200,6 +201,8 @@ > return "attach"; > } else if (origin == Flags_INTERNAL) { > return "internal"; > + } else if (origin == Flags_JIMAGE_RESOURCE) { > + return "jimage"; > } else { > throw new IllegalStateException( > "Unknown flag origin " + origin + " is detected in " + name); > @@ -484,6 +487,7 @@ > Flags_ERGONOMIC = db.lookupIntConstant("JVMFlag::ERGONOMIC").intValue(); > Flags_ATTACH_ON_DEMAND = db.lookupIntConstant("JVMFlag::ATTACH_ON_DEMAND").intValue(); > Flags_INTERNAL = db.lookupIntConstant("JVMFlag::INTERNAL").intValue(); > + Flags_JIMAGE_RESOURCE = db.lookupIntConstant("JVMFlag::JIMAGE").intValue(); > Flags_VALUE_ORIGIN_MASK = db.lookupIntConstant("JVMFlag::VALUE_ORIGIN_MASK").intValue(); > Flags_ORIG_COMMAND_LINE = db.lookupIntConstant("JVMFlag::ORIG_COMMAND_LINE").intValue(); > oopSize = db.lookupIntConstant("oopSize").intValue(); From mark.reinhold at oracle.com Wed Oct 23 20:25:52 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 23 Oct 2019 13:25:52 -0700 Subject: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options In-Reply-To: References: <20191021202253.825695282@eggemoggin.niobe.net> <20191022122232.395077958@eggemoggin.niobe.net> <55C347A2-D163-40E5-B9DF-C5791619BF12@oracle.com> <20191022153628.417897318@eggemoggin.niobe.net> <20191023120711.232005374@eggemoggin.niobe.net> Message-ID: <20191023132552.159905052@eggemoggin.niobe.net> 2019/10/23 12:37:56 -0700, bob.vandette at oracle.com: >> On Oct 23, 2019, at 3:07 PM, mark.reinhold at oracle.com wrote: >> ... >> >> Addendum: To keep things sane for JFR and the serviceability agent, >> I had to propagate this change through to those subsystems. >> >> Relative patch below; original webrev updated in place >> (https://cr.openjdk.java.net/~mr/rev/8232080/). >> >> Okay? > > Looks good. I?m sure you did this but I scanned the entire JDK > sources and didn?t see any other uses of JVMFlag:: that would need to > be updated. Yep, I did that, and didn?t see anything else either. Thanks, - Mark From leo.korinth at oracle.com Thu Oct 24 13:04:41 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 24 Oct 2019 15:04:41 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <1c57c422-2b29-d5e7-ac72-17cbaedd073a@oracle.com> Message-ID: <13df5389-b5d1-74f6-b673-b9e87c07c3aa@oracle.com> On 22/10/2019 21:37, Kim Barrett wrote: >> On Oct 22, 2019, at 11:17 AM, Leo Korinth wrote: >> >> On 21/10/2019 23:48, Kim Barrett wrote: >>>> On Oct 18, 2019, at 4:20 AM, Leo Korinth wrote: >>> src/hotspot/share/gc/shared/collectedHeap.cpp >>> 336 void CollectedHeap::check_for_non_bad_heap_word_value(HeapWord* addr, size_t size) { >>>> Please take an extra look at CollectedHeap::check_for_non_bad_heap_word_value, >>>> it was buggy before (but never called), It is now called (and hopefully >>>> correct). >>> I don't understand "but never called" as it looks like it has been >>> called all along from MemAllocator::allocate_outside_tlab. Except >>> that's only when UseTLAB is false, and it always defaults true if any >>> of C1, C2, or JVMCI are included. We do have some -UseTLAB tests >>> though, and they aren't all with CMS, so I'm not sure how a problem >>> here hasn't already appeared. > >>> Because I don't understand "but never called" I'm failing to >>> understand how this hasn't shown up as a problem before. Seems like it >>> should never have worked and there would be test failures at least. >> >> Sorry, I was sloppy in my description, it has not been called from our /test suite/. Special command line option (CheckMemoryInitialization && ZapUnusedHeapArea) needs to be given to the JVM for the check to be done. -XX:+CheckMemoryInitialization is only used in one test that hard codes serial gc. That -XX:+CheckMemoryInitialization flag looks quite unused might be a problem in itself, I do not know. > > Thanks for the explanation. I'd overlooked CheckMemoryInitialization. > That actually seems like a reasonable use of a develop/debug option. > Seems like there should be more tests though :) Another RFE for you > to file... https://bugs.openjdk.java.net/browse/JDK-8232966 > > >>> Part of the problem here is that Copy::fill_to_words takes a juint >>> fill value that it duplicates in high/low on 64bit platforms. That >>> seems wrong; shouldn't it take a platform-word sized value and just >>> store that? But making any such change is going to require some care. >>> And it results in the CollectedHeap implementation's use of intptr_t >>> on 64bit platforms comparing badHeapWord (a juint, so 32bits) with >>> 64bit (((julong)badHeapWord << 32) | badHeapWord). So how did this >>> ever manage to pass testing? >>> However, on a 64bit platform the new code (and the old >>> GenCollectedHeap code) is only checking every other 32bit value. The >>> step distance is 8 bytes but the value read at each step is only 4 >>> bytes. >> >> The old code did not work, but what is wrong with the new code? ++ju_addr increments /four/ bytes at a time (ju_addr is a pointer to uint32_t), and (if I am not mistaken) the full memory range is checked as the sum of reinterpret_cast(addr + size) is done in words (not juints) and /then/ casted to juint*. >> >> Or did I miss something? > > Sorry about that; you are correct. I got confused by the fill_to_words > weirdness and how it interacts here. > > Thanks Kim! /Leo From leo.korinth at oracle.com Thu Oct 24 18:03:59 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 24 Oct 2019 20:03:59 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: Message-ID: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> Fixes after suggestions from Coleen, David, Erik, Igor and Kim: http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) Thanks, Leo On 18/10/2019 10:20, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files > are correct, if someone can test those architectures, that would be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From kim.barrett at oracle.com Thu Oct 24 19:26:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Oct 2019 15:26:09 -0400 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> References: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> Message-ID: > On Oct 24, 2019, at 2:03 PM, Leo Korinth wrote: > > Fixes after suggestions from Coleen, David, Erik, Igor and Kim: > > http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) > http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) Looks good. One tiny nit in a comment. I don't need a new webrev for this: src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp 301 * in the nursery, this would happen for humongous objects. Change "," to ";". From thomas.schatzl at oracle.com Thu Oct 24 21:16:09 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 24 Oct 2019 14:16:09 -0700 (PDT) Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector Message-ID: <7868d4b1-9546-44da-847f-c774537e8f91@default> Hi, some additional thoughts I had when looking through the change: - BlockOffsetArray/BlockOffsetArrayContigSpace inheritance could be folded in a separate CR Other minor removals that could be done here: - GCStats::kind() / GCStats::Name enum / GCStats::average_promoted_in_bytes() / GCStats::padded_average_promoted_in_bytes() are unused. - unused flags from gc_globals.hpp (I assume that there are more from globals.hpp that are now unused but it's daunting to go through all of them :)): GCTaskTimeStampEntries (this one has been unused before the CMS change so start the deprecation/removal in a different RFE) OldPLABWeight ResizeOldPLAB VerifyBlockOffsetArray Made obsolete by this change. - MarkWord::must_be_preserved_for_cms_scavenge() should be removed Looks good otherwise. Thomas ----- Original Message ----- From: leo.korinth at oracle.com To: hotspot-dev at openjdk.java.net Sent: Thursday, October 24, 2019 8:05:37 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector Fixes after suggestions from Coleen, David, Erik, Igor and Kim: http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) Thanks, Leo On 18/10/2019 10:20, Leo Korinth wrote: > Hi, > > Here is a patch that removes the CMS GC. > > I have neither tested arm nor ppc; I hope my changes to those .ad files > are correct, if someone can test those architectures, that would be great. > > Please take an extra look at > CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before > (but never called), It is now called (and hopefully correct). > > I have tried to remove most parts of CMS. I have not made it a goal to > remove all traces of CMS. I guess there are much more to cleanup, and > suggestions of more to remove are welcomed. I think more complicated > cleanups should be dealt with in separate enhancements. > > Not fully addressed in code, but an issue that has to be dealt with, how > do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be > obsoleted, though I do not know if we have any precedence obsoleting -X > options. > > My patch prints: > > $ java -Xconcgc -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC > > I guess that is not enough for being obsolete, compare with: > > $ java -XX:UseConcMarkSweepGC -jar Notepad.jar > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option > UseConcMarkSweepGC; support was removed in 14.0 > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8232365 > > Webrev: > ? http://cr.openjdk.java.net/~lkorinth/8232365/00 > > Testing: > ? tier 1-5. > > Thanks, > Leo From vladimir.kozlov at oracle.com Fri Oct 25 00:42:33 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Oct 2019 17:42:33 -0700 Subject: [14] RFR(S) 8225464: Obsolete TraceNMethodInstalls flag Message-ID: http://cr.openjdk.java.net/~kvn/8225464/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8225464 This is diagnostic flag - no CSR is needed. In JDK 13 it was replaced with UL option -Xlog:nmethod+install [1]. Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8222371 From david.holmes at oracle.com Fri Oct 25 00:45:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2019 10:45:10 +1000 Subject: [14] RFR(S) 8225464: Obsolete TraceNMethodInstalls flag In-Reply-To: References: Message-ID: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> Looks fine to me! Thanks, David On 25/10/2019 10:42 am, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8225464/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8225464 > > This is diagnostic flag - no CSR is needed. > > In JDK 13 it was replaced with UL option -Xlog:nmethod+install [1]. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8222371 From vladimir.kozlov at oracle.com Fri Oct 25 01:08:26 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Oct 2019 18:08:26 -0700 Subject: [14] RFR(S) 8225464: Obsolete TraceNMethodInstalls flag In-Reply-To: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> References: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> Message-ID: <707FDE73-9BF5-4616-B565-DA7408C609D8@oracle.com> Thank you, David Vladimir > On Oct 24, 2019, at 5:45 PM, David Holmes wrote: > > Looks fine to me! > > Thanks, > David > >> On 25/10/2019 10:42 am, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8225464/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225464 >> This is diagnostic flag - no CSR is needed. >> In JDK 13 it was replaced with UL option -Xlog:nmethod+install [1]. >> Thanks, >> Vladimir >> [1] https://bugs.openjdk.java.net/browse/JDK-8222371 From tobias.hartmann at oracle.com Fri Oct 25 07:50:30 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 25 Oct 2019 09:50:30 +0200 Subject: [14] RFR(S) 8225464: Obsolete TraceNMethodInstalls flag In-Reply-To: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> References: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> Message-ID: +1 Best regards, Tobias On 25.10.19 02:45, David Holmes wrote: > Looks fine to me! > > Thanks, > David > > On 25/10/2019 10:42 am, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8225464/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8225464 >> >> This is diagnostic flag - no CSR is needed. >> >> In JDK 13 it was replaced with UL option -Xlog:nmethod+install [1]. >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222371 From leo.korinth at oracle.com Fri Oct 25 08:31:54 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Fri, 25 Oct 2019 10:31:54 +0200 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> Message-ID: <5f241bdf-49f8-5969-ad86-ae2d197d6596@oracle.com> On 24/10/2019 21:26, Kim Barrett wrote: >> On Oct 24, 2019, at 2:03 PM, Leo Korinth wrote: >> >> Fixes after suggestions from Coleen, David, Erik, Igor and Kim: >> >> http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) >> http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) > > Looks good. > > One tiny nit in a comment. I don't need a new webrev for this: > > src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp > 301 * in the nursery, this would happen for humongous objects. > > Change "," to ";". > Fixed. Thanks, Leo From vladimir.kozlov at oracle.com Fri Oct 25 12:31:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Oct 2019 05:31:16 -0700 Subject: [14] RFR(S) 8225464: Obsolete TraceNMethodInstalls flag In-Reply-To: References: <7c701bc1-d943-ed50-c3b4-ed572f6ffa74@oracle.com> Message-ID: <7136cb8a-1799-91fd-f518-e4a87efe7677@oracle.com> Thank you, Tobias Vladimir On 10/25/19 12:50 AM, Tobias Hartmann wrote: > +1 > > Best regards, > Tobias > > On 25.10.19 02:45, David Holmes wrote: >> Looks fine to me! >> >> Thanks, >> David >> >> On 25/10/2019 10:42 am, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8225464/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8225464 >>> >>> This is diagnostic flag - no CSR is needed. >>> >>> In JDK 13 it was replaced with UL option -Xlog:nmethod+install [1]. >>> >>> Thanks, >>> Vladimir >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8222371 From matthias.baesken at sap.com Fri Oct 25 13:46:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 25 Oct 2019 13:46:22 +0000 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY Message-ID: Hello, please review this small change . It adds some missing FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233013 http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ (but in case you think we do not need the freeing because of the calls are followed by " vm_exit_during_initialization" calls, then probably the already in-place freeing before those calls could be removed too for consistency see http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/solaris/os_solaris.cpp.frames.html lines 456 / 466) Additionally I was unsure where the freeing of "char* s" from ... src/hotspot/share/compiler/directivesParser.cpp , line 313 case JSON_STRING: if (option_key->flag_type != ccstrFlag && option_key->flag_type != ccstrlistFlag) { . . . } else { char* s = NEW_C_HEAP_ARRAY(char, v->str.length+1, mtCompiler); strncpy(s, v->str.start, v->str.length + 1); s[v->str.length] = '\0'; (set->*test)((void *)&s); } break; occurs, maybe someone can tell ? Thanks, Matthias From kim.barrett at oracle.com Sat Oct 26 00:57:10 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Oct 2019 20:57:10 -0400 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: References: Message-ID: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> > On Oct 25, 2019, at 9:46 AM, Baesken, Matthias wrote: > > Hello, please review this small change . It adds some missing FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8233013 > http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ I don?t think any of the proposed additional FREE_C_HEAP_ARRAY uses are needed. > (but in case you think we do not need the freeing because of the calls are followed by " vm_exit_during_initialization" calls, > then probably the already in-place freeing before those calls could be removed too for consistency see > > http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/solaris/os_solaris.cpp.frames.html > > lines 456 / 466) I don?t think those are needed either. It?s not clear that it?s worth the effort of removing them, given JEP 362. > Additionally I was unsure where the freeing of "char* s" from ... > > src/hotspot/share/compiler/directivesParser.cpp , line 313 > > case JSON_STRING: > if (option_key->flag_type != ccstrFlag && option_key->flag_type != ccstrlistFlag) { > . . . > } else { > char* s = NEW_C_HEAP_ARRAY(char, v->str.length+1, mtCompiler); > strncpy(s, v->str.start, v->str.length + 1); > s[v->str.length] = '\0'; > (set->*test)((void *)&s); > } > break; > > occurs, maybe someone can tell ? That array seems to be getting stored in the directive set, although I haven?t fully traced through the code. It is presumably no longer the responsibility of the allocating code to free it. From david.holmes at oracle.com Sun Oct 27 22:32:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Oct 2019 08:32:23 +1000 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> Message-ID: <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> On 26/10/2019 10:57 am, Kim Barrett wrote: >> On Oct 25, 2019, at 9:46 AM, Baesken, Matthias wrote: >> >> Hello, please review this small change . It adds some missing FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . >> >> bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8233013 >> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ > > I don?t think any of the proposed additional FREE_C_HEAP_ARRAY uses are needed. Not essential but also not harmful. See below ... >> (but in case you think we do not need the freeing because of the calls are followed by " vm_exit_during_initialization" calls, >> then probably the already in-place freeing before those calls could be removed too for consistency see >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/solaris/os_solaris.cpp.frames.html >> >> lines 456 / 466) > > I don?t think those are needed either. These stem from a time when there was still the view that vm_exit_during_initialization could/should unload the VM rather than blow away the hosting process (which may not be the launcher). I think that is a battle we have abandoned now. I think this is going to be messy of we try to fight the consistency battle in this area. But I can see an argument for putting in the free call if we wanted to allow the code to be more easily examined by code checkers that were looking at correct usage here. So I don't object to this cleanup. > It?s not clear that it?s worth the effort of removing them, given JEP 362. > >> Additionally I was unsure where the freeing of "char* s" from ... >> >> src/hotspot/share/compiler/directivesParser.cpp , line 313 >> >> case JSON_STRING: >> if (option_key->flag_type != ccstrFlag && option_key->flag_type != ccstrlistFlag) { >> . . . >> } else { >> char* s = NEW_C_HEAP_ARRAY(char, v->str.length+1, mtCompiler); >> strncpy(s, v->str.start, v->str.length + 1); >> s[v->str.length] = '\0'; >> (set->*test)((void *)&s); >> } >> break; >> >> occurs, maybe someone can tell ? > > That array seems to be getting stored in the directive set, although I haven?t fully traced > through the code. It is presumably no longer the responsibility of the allocating code to > free it. I would agree with that. Thanks, David From kim.barrett at oracle.com Mon Oct 28 03:35:02 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 27 Oct 2019 23:35:02 -0400 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> Message-ID: <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> > On Oct 27, 2019, at 6:32 PM, David Holmes wrote: > > On 26/10/2019 10:57 am, Kim Barrett wrote: >>> On Oct 25, 2019, at 9:46 AM, Baesken, Matthias wrote: >>> >>> Hello, please review this small change . It adds some missing FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . >>> >>> bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8233013 >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ >> I don?t think any of the proposed additional FREE_C_HEAP_ARRAY uses are needed. > > Not essential but also not harmful. See below ? I don't agree that it's harmless. See below ... >>> (but in case you think we do not need the freeing because of the calls are followed by " vm_exit_during_initialization" calls, >>> then probably the already in-place freeing before those calls could be removed too for consistency see >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/solaris/os_solaris.cpp.frames.html >>> >>> lines 456 / 466) >> I don?t think those are needed either. > > These stem from a time when there was still the view that vm_exit_during_initialization could/should unload the VM rather than blow away the hosting process (which may not be the launcher). I think that is a battle we have abandoned now. I agree; that ship has sailed. > I think this is going to be messy of we try to fight the consistency battle in this area. But I can see an argument for putting in the free call if we wanted to allow the code to be more easily examined by code checkers that were looking at correct usage here. So I don't object to this cleanup. I don't think these help any actually useful code checkers (e.g. ones which look at more than a single translation unit), which will see that the code path leads to abort or exit. I really dislike adding effectively useless code. It expands the code surface area for no good reason. That has various knock-on effects. For example, some of these lines have been modified multiple times over the years as our memory management infrastructure has changed. If we really want consistency, I'd remove the solaris-specific useless code. But because of JEP 362, that doesn't seem to me to be worth the effort. Of course, we've probably now spent more effort... The best way to handle this sort of thing would be to capture the temporary buf in an RAII object at the point of construction. That's true in many other places too. From david.holmes at oracle.com Mon Oct 28 03:57:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Oct 2019 13:57:56 +1000 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> Message-ID: <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> Hi Kim, On 28/10/2019 1:35 pm, Kim Barrett wrote: >> On Oct 27, 2019, at 6:32 PM, David Holmes wrote: >> >> On 26/10/2019 10:57 am, Kim Barrett wrote: >>>> On Oct 25, 2019, at 9:46 AM, Baesken, Matthias wrote: >>>> >>>> Hello, please review this small change . It adds some missing FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . >>>> >>>> bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8233013 >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ >>> I don?t think any of the proposed additional FREE_C_HEAP_ARRAY uses are needed. >> >> Not essential but also not harmful. See below ? > > I don't agree that it's harmless. See below ... > >>>> (but in case you think we do not need the freeing because of the calls are followed by " vm_exit_during_initialization" calls, >>>> then probably the already in-place freeing before those calls could be removed too for consistency see >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/solaris/os_solaris.cpp.frames.html >>>> >>>> lines 456 / 466) >>> I don?t think those are needed either. >> >> These stem from a time when there was still the view that vm_exit_during_initialization could/should unload the VM rather than blow away the hosting process (which may not be the launcher). I think that is a battle we have abandoned now. > > I agree; that ship has sailed. > >> I think this is going to be messy of we try to fight the consistency battle in this area. But I can see an argument for putting in the free call if we wanted to allow the code to be more easily examined by code checkers that were looking at correct usage here. So I don't object to this cleanup. > > I don't think these help any actually useful code checkers (e.g. ones > which look at more than a single translation unit), which will see > that the code path leads to abort or exit. It requires that you have to teach the tool about vm_exit_during_initialization. I don't know if that is a hurdle or not but it seems an unnecessary complexity to have to add. > I really dislike adding effectively useless code. It expands the code > surface area for no good reason. That has various knock-on effects. > For example, some of these lines have been modified multiple times > over the years as our memory management infrastructure has changed. I'm not sure I see your point re "knock-on effects". > If we really want consistency, I'd remove the solaris-specific useless > code. But because of JEP 362, that doesn't seem to me to be worth the > effort. Of course, we've probably now spent more effort... > > The best way to handle this sort of thing would be to capture the > temporary buf in an RAII object at the point of construction. That's > true in many other places too. So if we had been using RAII then this somehow makes the freeing code not useless? The syntax shouldn't make a difference. I'm fine either way with this change. I still see it as unnecessary but harmless (by my own definition of "harm"). Cheers, David From matthias.baesken at sap.com Mon Oct 28 13:37:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 28 Oct 2019 13:37:20 +0000 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> Message-ID: Hi David / Kim , thanks for your comments. I think I just document the outcome of this little discussion in https://bugs.openjdk.java.net/browse/JDK-8233013 and then close the item . Best regards, Matthias > > Hi Kim, > > On 28/10/2019 1:35 pm, Kim Barrett wrote: > >> On Oct 27, 2019, at 6:32 PM, David Holmes > wrote: > >> > >> On 26/10/2019 10:57 am, Kim Barrett wrote: > >>>> On Oct 25, 2019, at 9:46 AM, Baesken, Matthias > wrote: > >>>> > >>>> Hello, please review this small change . It adds some missing > FREE_C_HEAP_ARRAY calls to os::init_system_properties_values . > >>>> > >>>> bug/webrev : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8233013 > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/ > >>> I don?t think any of the proposed additional FREE_C_HEAP_ARRAY uses > are needed. > >> > >> Not essential but also not harmful. See below ? > > > > I don't agree that it's harmless. See below ... > > > >>>> (but in case you think we do not need the freeing because of the calls > are followed by " vm_exit_during_initialization" calls, > >>>> then probably the already in-place freeing before those calls could be > removed too for consistency see > >>>> > >>>> > http://cr.openjdk.java.net/~mbaesken/webrevs/8233013.1/src/hotspot/os/ > solaris/os_solaris.cpp.frames.html > >>>> > >>>> lines 456 / 466) > >>> I don?t think those are needed either. > >> > >> These stem from a time when there was still the view that > vm_exit_during_initialization could/should unload the VM rather than blow > away the hosting process (which may not be the launcher). I think that is a > battle we have abandoned now. > > > > I agree; that ship has sailed. > > > >> I think this is going to be messy of we try to fight the consistency battle in > this area. But I can see an argument for putting in the free call if we wanted > to allow the code to be more easily examined by code checkers that were > looking at correct usage here. So I don't object to this cleanup. > > > > I don't think these help any actually useful code checkers (e.g. ones > > which look at more than a single translation unit), which will see > > that the code path leads to abort or exit. > > It requires that you have to teach the tool about > vm_exit_during_initialization. I don't know if that is a hurdle or not > but it seems an unnecessary complexity to have to add. > > > I really dislike adding effectively useless code. It expands the code > > surface area for no good reason. That has various knock-on effects. > > For example, some of these lines have been modified multiple times > > over the years as our memory management infrastructure has changed. > > I'm not sure I see your point re "knock-on effects". > > > If we really want consistency, I'd remove the solaris-specific useless > > code. But because of JEP 362, that doesn't seem to me to be worth the > > effort. Of course, we've probably now spent more effort... > > > > The best way to handle this sort of thing would be to capture the > > temporary buf in an RAII object at the point of construction. That's > > true in many other places too. > > So if we had been using RAII then this somehow makes the freeing code > not useless? The syntax shouldn't make a difference. > > I'm fine either way with this change. I still see it as unnecessary but > harmless (by my own definition of "harm"). > > Cheers, > David From leo.korinth at oracle.com Mon Oct 28 16:30:59 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 28 Oct 2019 17:30:59 +0100 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <7868d4b1-9546-44da-847f-c774537e8f91@default> References: <7868d4b1-9546-44da-847f-c774537e8f91@default> Message-ID: <10d87423-b5c2-db63-3fac-1c396dc5f0ad@oracle.com> On 24/10/2019 23:16, Thomas Schatzl wrote: > Hi, > > some additional thoughts I had when looking through the change: > > - BlockOffsetArray/BlockOffsetArrayContigSpace inheritance could be folded in a separate CR I have filed: https://bugs.openjdk.java.net/browse/JDK-8233074 > Other minor removals that could be done here: > > - GCStats::kind() / GCStats::Name enum / GCStats::average_promoted_in_bytes() / GCStats::padded_average_promoted_in_bytes() are unused. Thanks, removed. > > - unused flags from gc_globals.hpp (I assume that there are more from globals.hpp that are now unused but it's daunting to go through all of them :)): > > GCTaskTimeStampEntries (this one has been unused before the CMS change so start the deprecation/removal in a different RFE) Many thanks for this find!!! I have filed: https://bugs.openjdk.java.net/browse/JDK-8233029 > > OldPLABWeight will obsolete > ResizeOldPLAB will obsolete > VerifyBlockOffsetArray will remove (develop flag) I also saw (unrelated to this CMS removal) that TLABStats probably should be obsoleted/removed (it is deprecated now, but in practice obsoleted), should I file a bug for that? Also unrelated to this CMS removal, should I file a bug for obsolete/removal of PrintGC/PrintGCDetails (deprecated now), or do we want to keep it deprecated? > > Made obsolete by this change. > > - MarkWord::must_be_preserved_for_cms_scavenge() should be removed Will remove. > > Looks good otherwise. > > Thomas > Fixes after suggestions from Kim and Thomas: http://cr.openjdk.java.net/~lkorinth/8232365/01_02/ (incremental) http://cr.openjdk.java.net/~lkorinth/8232365/02/ (full) Thanks, Leo > ----- Original Message ----- > From: leo.korinth at oracle.com > To: hotspot-dev at openjdk.java.net > Sent: Thursday, October 24, 2019 8:05:37 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector > > Fixes after suggestions from Coleen, David, Erik, Igor and Kim: > > http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) > http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) > > Thanks, > Leo > > On 18/10/2019 10:20, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad files >> are correct, if someone can test those architectures, that would be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal to >> remove all traces of CMS. I guess there are much more to cleanup, and >> suggestions of more to remove are welcomed. I think more complicated >> cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, how >> do I obsolete -Xconcgc and -Xnoconcgc? I believe the option should be >> obsoleted, though I do not know if we have any precedence obsoleting -X >> options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ? tier 1-5. >> >> Thanks, >> Leo From kim.barrett at oracle.com Mon Oct 28 20:34:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 16:34:57 -0400 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <10d87423-b5c2-db63-3fac-1c396dc5f0ad@oracle.com> References: <7868d4b1-9546-44da-847f-c774537e8f91@default> <10d87423-b5c2-db63-3fac-1c396dc5f0ad@oracle.com> Message-ID: <508E1D07-4124-44AF-B3F0-D5F5F6D83376@oracle.com> > On Oct 28, 2019, at 12:30 PM, Leo Korinth wrote: > > On 24/10/2019 23:16, Thomas Schatzl wrote: >> Other minor removals that could be done here: >> - GCStats::kind() / GCStats::Name enum / GCStats::average_promoted_in_bytes() / GCStats::padded_average_promoted_in_bytes() are unused. > > Thanks, removed. With these removals, GCStats seems pretty vacuous. Maybe another followup to look at further cleanup there? > I also saw (unrelated to this CMS removal) that TLABStats probably should be obsoleted/removed (it is deprecated now, but in practice obsoleted), should I file a bug for that? Yes. > Also unrelated to this CMS removal, should I file a bug for obsolete/removal of PrintGC/PrintGCDetails (deprecated now), or do we want to keep it deprecated? Don't forget -Xloggc. I don't have an informed opinion as to whether it's time to remove them. One would want some idea of how prevelent these formerly very widely used options still are. (For reference, the change that added them back as deprecated options (after having been removed by the conversion of GC to use UL) was JDK-8145180. See also JDK-8170636.) I guess it doesn?t hurt to have the RFE, even if we decide not to act on it immediately. > Fixes after suggestions from Kim and Thomas: > > http://cr.openjdk.java.net/~lkorinth/8232365/01_02/ (incremental) > http://cr.openjdk.java.net/~lkorinth/8232365/02/ (full) Looks good. From kim.barrett at oracle.com Mon Oct 28 21:48:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 17:48:56 -0400 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> Message-ID: <671F01EC-D3D8-44C0-94EF-8C4CA3AC147A@oracle.com> > On Oct 27, 2019, at 11:57 PM, David Holmes wrote: > > Hi Kim, > > On 28/10/2019 1:35 pm, Kim Barrett wrote: >>> On Oct 27, 2019, at 6:32 PM, David Holmes wrote: >>> I think this is going to be messy of we try to fight the consistency battle in this area. But I can see an argument for putting in the free call if we wanted to allow the code to be more easily examined by code checkers that were looking at correct usage here. So I don't object to this cleanup. >> I don't think these help any actually useful code checkers (e.g. ones >> which look at more than a single translation unit), which will see >> that the code path leads to abort or exit. > > It requires that you have to teach the tool about vm_exit_during_initialization. I don't know if that is a hurdle or not but it seems an unnecessary complexity to have to add. Any decent (i.e. usable IMO) code checker figures that out automatically. (A local-to-TU analysis such as a typical compiler might do might someday be aided by the C++11 [[noreturn]] attribute.) >> I really dislike adding effectively useless code. It expands the code >> surface area for no good reason. That has various knock-on effects. >> For example, some of these lines have been modified multiple times >> over the years as our memory management infrastructure has changed. > > I'm not sure I see your point re "knock-on effects?. This is useless code. And yet there have been multiple occasions when time has been spent (wasted, IMO) updating it. And it's more code to read (or glaze over and hopefully not miss something important nearby as a result). >> If we really want consistency, I'd remove the solaris-specific useless >> code. But because of JEP 362, that doesn't seem to me to be worth the >> effort. Of course, we've probably now spent more effort... >> The best way to handle this sort of thing would be to capture the >> temporary buf in an RAII object at the point of construction. That's >> true in many other places too. > > So if we had been using RAII then this somehow makes the freeing code not useless? The syntax shouldn't make a difference. The RAII suggestion is to ensure all return paths perform the cleanup. These vm_exit_xxx calls are not return paths, so no cleanup is needed on them. And if they were return paths (say the "exiting" function doesn't always abort/exit for some reason, like our report_vm_error_xxx functions, though I think there is code that expects/assumes exit behavior for some of them), the RAII handling would deal, while the pre-exit-function frees would be wrong. (Thinking about it some more, I think they were probably useless or wrong even in a world where we could terminate and cleanup a VM without terminating the containing process. But I don't really want to go down that rabbit hole.) > I'm fine either way with this change. I still see it as unnecessary but harmless (by my own definition of "harm"). I disagree with the "harmless" characterization, so think the change shouldn't be made. From kim.barrett at oracle.com Mon Oct 28 21:49:39 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 17:49:39 -0400 Subject: RFR [XS]: 8233013: deallocate memory after using NEW_C_HEAP_ARRAY In-Reply-To: References: <1319DADE-090E-4C73-A612-5708820928EA@oracle.com> <5f8edf7a-fbb1-df25-e724-188df042af8d@oracle.com> <7EC852CD-B327-448B-9C6D-5A234F485693@oracle.com> <07a727f6-9e4b-eee9-ffba-e3140b34c9ba@oracle.com> Message-ID: > On Oct 28, 2019, at 9:37 AM, Baesken, Matthias wrote: > > Hi David / Kim , thanks for your comments. > > I think I just document the outcome of this little discussion in https://bugs.openjdk.java.net/browse/JDK-8233013 > and then close the item . > > Best regards, Matthias I?m happy with that outcome. From thomas.schatzl at oracle.com Tue Oct 29 08:29:30 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Oct 2019 09:29:30 +0100 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <508E1D07-4124-44AF-B3F0-D5F5F6D83376@oracle.com> References: <7868d4b1-9546-44da-847f-c774537e8f91@default> <10d87423-b5c2-db63-3fac-1c396dc5f0ad@oracle.com> <508E1D07-4124-44AF-B3F0-D5F5F6D83376@oracle.com> Message-ID: Hi, On 28.10.19 21:34, Kim Barrett wrote: >> On Oct 28, 2019, at 12:30 PM, Leo Korinth wrote: >> >> On 24/10/2019 23:16, Thomas Schatzl wrote: >>> Other minor removals that could be done here: >>> - GCStats::kind() / GCStats::Name enum / GCStats::average_promoted_in_bytes() / GCStats::padded_average_promoted_in_bytes() are unused. >> >> Thanks, removed. > > With these removals, GCStats seems pretty vacuous. Maybe another > followup to look at further cleanup there? +1 for follow-up. > >> Also unrelated to this CMS removal, should I file a bug for obsolete/removal of PrintGC/PrintGCDetails (deprecated now), or do we want to keep it deprecated? > > Don't forget -Xloggc. I don't have an informed opinion as to whether > it's time to remove them. One would want some idea of how prevelent > these formerly very widely used options still are. (For reference, the > change that added them back as deprecated options (after having been > removed by the conversion of GC to use UL) was JDK-8145180. See also > JDK-8170636.) I guess it doesn?t hurt to have the RFE, even if we > decide not to act on it immediately. > >> Fixes after suggestions from Kim and Thomas: >> >> http://cr.openjdk.java.net/~lkorinth/8232365/01_02/ (incremental) >> http://cr.openjdk.java.net/~lkorinth/8232365/02/ (full) > > Looks good. > Looks good. Thanks, Thomas From magnus.ihse.bursie at oracle.com Tue Oct 29 09:50:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 29 Oct 2019 10:50:10 +0100 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> References: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> Message-ID: On 2019-10-24 20:03, Leo Korinth wrote: > Fixes after suggestions from Coleen, David, Erik, Igor and Kim: > > http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) > http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) Build changes now look fine. /Magnus > > Thanks, > Leo > > On 18/10/2019 10:20, Leo Korinth wrote: >> Hi, >> >> Here is a patch that removes the CMS GC. >> >> I have neither tested arm nor ppc; I hope my changes to those .ad >> files are correct, if someone can test those architectures, that >> would be great. >> >> Please take an extra look at >> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >> (but never called), It is now called (and hopefully correct). >> >> I have tried to remove most parts of CMS. I have not made it a goal >> to remove all traces of CMS. I guess there are much more to cleanup, >> and suggestions of more to remove are welcomed. I think more >> complicated cleanups should be dealt with in separate enhancements. >> >> Not fully addressed in code, but an issue that has to be dealt with, >> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >> should be obsoleted, though I do not know if we have any precedence >> obsoleting -X options. >> >> My patch prints: >> >> $ java -Xconcgc -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >> UseConcMarkSweepGC >> >> I guess that is not enough for being obsolete, compare with: >> >> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >> UseConcMarkSweepGC; support was removed in 14.0 >> >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >> >> Webrev: >> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >> >> Testing: >> ?? tier 1-5. >> >> Thanks, >> Leo From leo.korinth at oracle.com Tue Oct 29 10:42:34 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 29 Oct 2019 11:42:34 +0100 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <7868d4b1-9546-44da-847f-c774537e8f91@default> <10d87423-b5c2-db63-3fac-1c396dc5f0ad@oracle.com> <508E1D07-4124-44AF-B3F0-D5F5F6D83376@oracle.com> Message-ID: <7e5d4d02-53ec-421a-bf4d-81f0f58bc100@oracle.com> On 29/10/2019 09:29, Thomas Schatzl wrote: > Hi, > > On 28.10.19 21:34, Kim Barrett wrote: >>> On Oct 28, 2019, at 12:30 PM, Leo Korinth >>> wrote: >>> >>> On 24/10/2019 23:16, Thomas Schatzl wrote: >>>> Other minor removals that could be done here: >>>> - GCStats::kind() / GCStats::Name enum / >>>> GCStats::average_promoted_in_bytes() / >>>> GCStats::padded_average_promoted_in_bytes() are unused. >>> >>> Thanks, removed. >> >> With these removals, GCStats seems pretty vacuous.? Maybe another >> followup to look at further cleanup there? > > +1 for follow-up. filed: https://bugs.openjdk.java.net/browse/JDK-8233109 > >> >>> Also unrelated to this CMS removal, should I file a bug for >>> obsolete/removal of PrintGC/PrintGCDetails (deprecated now), or do we >>> want to keep it deprecated? >> >> Don't forget -Xloggc. I don't have an informed opinion as to whether >> it's time to remove them. One would want some idea of how prevelent >> these formerly very widely used options still are. (For reference, the >> change that added them back as deprecated options (after having been >> removed by the conversion of GC to use UL) was JDK-8145180. See also >> JDK-8170636.)? I guess it doesn?t hurt to have the RFE, even if we >> decide not to act on it immediately. filed: https://bugs.openjdk.java.net/browse/JDK-8233110 >> >>> Fixes after suggestions from Kim and Thomas: >>> >>> http://cr.openjdk.java.net/~lkorinth/8232365/01_02/ (incremental) >>> http://cr.openjdk.java.net/~lkorinth/8232365/02/ (full) >> >> Looks good. >> > > Looks good. > > Thanks, > ? Thomas Thanks Kim and Thomas! I will add you as reviewers. Is it starting to look okay for the rest of you? Thanks, Leo From leo.korinth at oracle.com Tue Oct 29 10:47:59 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 29 Oct 2019 11:47:59 +0100 Subject: RFR: 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector In-Reply-To: References: <848d38c7-124a-0630-b3c5-15c03309d356@oracle.com> Message-ID: On 29/10/2019 10:50, Magnus Ihse Bursie wrote: > On 2019-10-24 20:03, Leo Korinth wrote: >> Fixes after suggestions from Coleen, David, Erik, Igor and Kim: >> >> http://cr.openjdk.java.net/~lkorinth/8232365/00_01/ (incremental) >> http://cr.openjdk.java.net/~lkorinth/8232365/01/ (full) > Build changes now look fine. > > /Magnus Thanks Magnus, I will add you as a reviewer. /Leo >> >> Thanks, >> Leo >> >> On 18/10/2019 10:20, Leo Korinth wrote: >>> Hi, >>> >>> Here is a patch that removes the CMS GC. >>> >>> I have neither tested arm nor ppc; I hope my changes to those .ad >>> files are correct, if someone can test those architectures, that >>> would be great. >>> >>> Please take an extra look at >>> CollectedHeap::check_for_non_bad_heap_word_value, it was buggy before >>> (but never called), It is now called (and hopefully correct). >>> >>> I have tried to remove most parts of CMS. I have not made it a goal >>> to remove all traces of CMS. I guess there are much more to cleanup, >>> and suggestions of more to remove are welcomed. I think more >>> complicated cleanups should be dealt with in separate enhancements. >>> >>> Not fully addressed in code, but an issue that has to be dealt with, >>> how do I obsolete -Xconcgc and -Xnoconcgc? I believe the option >>> should be obsoleted, though I do not know if we have any precedence >>> obsoleting -X options. >>> >>> My patch prints: >>> >>> $ java -Xconcgc -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: -Xconcgc uses >>> UseConcMarkSweepGC >>> >>> I guess that is not enough for being obsolete, compare with: >>> >>> $ java -XX:UseConcMarkSweepGC -jar Notepad.jar >>> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option >>> UseConcMarkSweepGC; support was removed in 14.0 >>> >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8232365 >>> >>> Webrev: >>> ?? http://cr.openjdk.java.net/~lkorinth/8232365/00 >>> >>> Testing: >>> ?? tier 1-5. >>> >>> Thanks, >>> Leo > From matthias.baesken at sap.com Tue Oct 29 11:42:28 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Oct 2019 11:42:28 +0000 Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) Message-ID: 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 martin.doerr at sap.com Tue Oct 29 11:53:22 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Oct 2019 11:53:22 +0000 Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) In-Reply-To: References: Message-ID: 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 matthias.baesken at sap.com Tue Oct 29 12:25:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Oct 2019 12:25:24 +0000 Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) In-Reply-To: References: Message-ID: 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 martin.doerr at sap.com Tue Oct 29 12:48:27 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Oct 2019 12:48:27 +0000 Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) In-Reply-To: References: Message-ID: 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 matthias.baesken at sap.com Tue Oct 29 13:32:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Oct 2019 13:32:07 +0000 Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le) In-Reply-To: References: Message-ID: 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 mark.reinhold at oracle.com Tue Oct 29 19:43:47 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 29 Oct 2019 12:43:47 -0700 Subject: 14 RFR (XXS): 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 Message-ID: <20191029124347.21033166@eggemoggin.niobe.net> Bug: https://bugs.openjdk.java.net/browse/JDK-8233137 My earlier changes to vmError.cpp didn?t sufficiently guard against the vendor VM bug URL string being undefined (oops). This was revealed by fastdebug testing in the main-line CI. Thanks, - Mark diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp --- a/src/hotspot/share/utilities/vmError.cpp +++ b/src/hotspot/share/utilities/vmError.cpp @@ -128,12 +128,14 @@ static void print_bug_submit_message(outputStream *out, Thread *thread) { if (out == NULL) return; - out->print_raw_cr("# If you would like to submit a bug report, please visit:"); - out->print_raw ("# "); const char *url = Arguments::java_vendor_url_bug(); if (url == NULL || *url == '\0') url = JDK_Version::runtime_vendor_vm_bug_url(); - out->print_raw_cr(url); + if (url != NULL && *url != '\0') { + out->print_raw_cr("# If you would like to submit a bug report, please visit:"); + out->print_raw ("# "); + out->print_raw_cr(url); + } // If the crash is in native code, encourage user to submit a bug to the // provider of that code. if (thread && thread->is_Java_thread() && From thomas.stuefe at gmail.com Tue Oct 29 19:50:33 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Oct 2019 20:50:33 +0100 Subject: 14 RFR (XXS): 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 In-Reply-To: <20191029124347.21033166@eggemoggin.niobe.net> References: <20191029124347.21033166@eggemoggin.niobe.net> Message-ID: Hi Mark, Looks good. Thank you for fixing this. ..Thomas On Tue 29. Oct 2019 at 20:43, wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8233137 > > My earlier changes to vmError.cpp didn?t sufficiently guard against the > vendor VM bug URL string being undefined (oops). This was revealed by > fastdebug testing in the main-line CI. > > Thanks, > - Mark > > > diff --git a/src/hotspot/share/utilities/vmError.cpp > b/src/hotspot/share/utilities/vmError.cpp > --- a/src/hotspot/share/utilities/vmError.cpp > +++ b/src/hotspot/share/utilities/vmError.cpp > @@ -128,12 +128,14 @@ > > static void print_bug_submit_message(outputStream *out, Thread *thread) { > if (out == NULL) return; > - out->print_raw_cr("# If you would like to submit a bug report, please > visit:"); > - out->print_raw ("# "); > const char *url = Arguments::java_vendor_url_bug(); > if (url == NULL || *url == '\0') > url = JDK_Version::runtime_vendor_vm_bug_url(); > - out->print_raw_cr(url); > + if (url != NULL && *url != '\0') { > + out->print_raw_cr("# If you would like to submit a bug report, please > visit:"); > + out->print_raw ("# "); > + out->print_raw_cr(url); > + } > // If the crash is in native code, encourage user to submit a bug to the > // provider of that code. > if (thread && thread->is_Java_thread() && > From igor.ignatyev at oracle.com Tue Oct 29 19:51:23 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 29 Oct 2019 12:51:23 -0700 Subject: 14 RFR (XXS): 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 In-Reply-To: <20191029124347.21033166@eggemoggin.niobe.net> References: <20191029124347.21033166@eggemoggin.niobe.net> Message-ID: Hi Mark, the fix looks good to me. -- Igor > On Oct 29, 2019, at 12:43 PM, mark.reinhold at oracle.com wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233137 > > My earlier changes to vmError.cpp didn?t sufficiently guard against the > vendor VM bug URL string being undefined (oops). This was revealed by > fastdebug testing in the main-line CI. > > Thanks, > - Mark > > > diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp > --- a/src/hotspot/share/utilities/vmError.cpp > +++ b/src/hotspot/share/utilities/vmError.cpp > @@ -128,12 +128,14 @@ > > static void print_bug_submit_message(outputStream *out, Thread *thread) { > if (out == NULL) return; > - out->print_raw_cr("# If you would like to submit a bug report, please visit:"); > - out->print_raw ("# "); > const char *url = Arguments::java_vendor_url_bug(); > if (url == NULL || *url == '\0') > url = JDK_Version::runtime_vendor_vm_bug_url(); > - out->print_raw_cr(url); > + if (url != NULL && *url != '\0') { > + out->print_raw_cr("# If you would like to submit a bug report, please visit:"); > + out->print_raw ("# "); > + out->print_raw_cr(url); > + } > // If the crash is in native code, encourage user to submit a bug to the > // provider of that code. > if (thread && thread->is_Java_thread() && From mandy.chung at oracle.com Tue Oct 29 19:52:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 29 Oct 2019 12:52:42 -0700 Subject: 14 RFR (XXS): 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 In-Reply-To: <20191029124347.21033166@eggemoggin.niobe.net> References: <20191029124347.21033166@eggemoggin.niobe.net> Message-ID: <22c0571e-c608-44e5-05af-1f2417731ac9@oracle.com> Looks good. Mandy On 10/29/19 12:43 PM, mark.reinhold at oracle.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8233137 > > My earlier changes to vmError.cpp didn?t sufficiently guard against the > vendor VM bug URL string being undefined (oops). This was revealed by > fastdebug testing in the main-line CI. > > Thanks, > - Mark > > > diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp > --- a/src/hotspot/share/utilities/vmError.cpp > +++ b/src/hotspot/share/utilities/vmError.cpp > @@ -128,12 +128,14 @@ > > static void print_bug_submit_message(outputStream *out, Thread *thread) { > if (out == NULL) return; > - out->print_raw_cr("# If you would like to submit a bug report, please visit:"); > - out->print_raw ("# "); > const char *url = Arguments::java_vendor_url_bug(); > if (url == NULL || *url == '\0') > url = JDK_Version::runtime_vendor_vm_bug_url(); > - out->print_raw_cr(url); > + if (url != NULL && *url != '\0') { > + out->print_raw_cr("# If you would like to submit a bug report, please visit:"); > + out->print_raw ("# "); > + out->print_raw_cr(url); > + } > // If the crash is in native code, encourage user to submit a bug to the > // provider of that code. > if (thread && thread->is_Java_thread() && From mark.reinhold at oracle.com Tue Oct 29 19:55:02 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 29 Oct 2019 12:55:02 -0700 Subject: 14 RFR (XXS): 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 In-Reply-To: <22c0571e-c608-44e5-05af-1f2417731ac9@oracle.com> References: <20191029124347.21033166@eggemoggin.niobe.net> <22c0571e-c608-44e5-05af-1f2417731ac9@oracle.com> Message-ID: <20191029125502.396443473@eggemoggin.niobe.net> Mandy, Thomas, Igor -- thanks for the quick reviews! - Mark From brent.christian at oracle.com Thu Oct 31 22:50:01 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 31 Oct 2019 15:50:01 -0700 Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized Message-ID: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> Hi, Please review my change to backout JDK-8212117: http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/ Background: A couple months ago, JDK-8212117[1] was fixed[2]. It changed the behavior of the 2-arg and 3-arg Class.forName methods to ensure that linking is performed. This conforms to the specification[3], which states that the method "attempts to locate, load, and link the class". In the process, 8181144[7] was also resolved. It was acknowledged that new LinkageErrors could be introduced as a result - for instance, in cases where Class.forName() loads, but never uses, an unlinkable class. Such uncovered errors would need to be fixed. Well, after a few promoted builds with the JDK-8212117 change, it looks like new LinkageErrors will be more widespread than anticipated (JDK-8231924[4], for example). This change to long-standing behavior would cause too great an incompatibility. (See Mandy's comment[5] for more.) So the proposal is to revert the JDK-8212117 change, along with a couple follow-up tasks: * Update the Class::forName API spec to match the long-standing behavior (i.e. no linking if initialize=false) - JDK-8233272 [6] * Reopen JDK-8181144[7] for further investigation of JDI VirtualMachine::allClasses and JVM TI AllLoadedClasses Thanks, -Brent ============== 1. https://bugs.openjdk.java.net/browse/JDK-8212117 2. http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html 3. https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader) 4. https://bugs.openjdk.java.net/browse/JDK-8231924 5. https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501 6. https://bugs.openjdk.java.net/browse/JDK-8233272 7. https://bugs.openjdk.java.net/browse/JDK-8181144 From david.holmes at oracle.com Thu Oct 31 23:04:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Nov 2019 09:04:33 +1000 Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized In-Reply-To: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> References: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> Message-ID: <748167a8-e763-387e-4508-bae371137de2@oracle.com> Hi Brent, This looks like an accurate backout to me. Thanks, David ----- On 1/11/2019 8:50 am, Brent Christian wrote: > Hi, > > Please review my change to backout JDK-8212117: > http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/ > > Background: > > A couple months ago, JDK-8212117[1] was fixed[2].? It changed the > behavior of the 2-arg and 3-arg Class.forName methods to ensure that > linking is performed.? This conforms to the specification[3], which > states that the method "attempts to locate, load, and link the class". > In the process, 8181144[7] was also resolved. > > It was acknowledged that new LinkageErrors could be introduced as a > result - for instance, in cases where Class.forName() loads, but never > uses, an unlinkable class.? Such uncovered errors would need to be fixed. > > Well, after a few promoted builds with the JDK-8212117 change, it looks > like new LinkageErrors will be more widespread than anticipated > (JDK-8231924[4], for example).? This change to long-standing behavior > would cause too great an incompatibility.? (See Mandy's comment[5] for > more.) > > So the proposal is to revert the JDK-8212117 change, along with a couple > follow-up tasks: > > * Update the Class::forName API spec to match the long-standing behavior > (i.e. no linking if initialize=false) - JDK-8233272 [6] > > * Reopen JDK-8181144[7] for further investigation of JDI > VirtualMachine::allClasses and JVM TI AllLoadedClasses > > Thanks, > -Brent > > ============== > 1. https://bugs.openjdk.java.net/browse/JDK-8212117 > > 2. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html > > > 3. > https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader) > > > 4. https://bugs.openjdk.java.net/browse/JDK-8231924 > > 5. > https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501 > > > 6. https://bugs.openjdk.java.net/browse/JDK-8233272 > > 7. https://bugs.openjdk.java.net/browse/JDK-8181144 > > From mandy.chung at oracle.com Thu Oct 31 23:20:51 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2019 16:20:51 -0700 Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized In-Reply-To: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> References: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> Message-ID: <67aa28d7-4d1c-f886-c909-2cdbdf3a536f@oracle.com> This looks good to me. Mandy On 10/31/19 3:50 PM, Brent Christian wrote: > Hi, > > Please review my change to backout JDK-8212117: > http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/ > > Background: > > A couple months ago, JDK-8212117[1] was fixed[2].? It changed the > behavior of the 2-arg and 3-arg Class.forName methods to ensure that > linking is performed.? This conforms to the specification[3], which > states that the method "attempts to locate, load, and link the class". > In the process, 8181144[7] was also resolved. > > It was acknowledged that new LinkageErrors could be introduced as a > result - for instance, in cases where Class.forName() loads, but never > uses, an unlinkable class.? Such uncovered errors would need to be fixed. > > Well, after a few promoted builds with the JDK-8212117 change, it > looks like new LinkageErrors will be more widespread than anticipated > (JDK-8231924[4], for example).? This change to long-standing behavior > would cause too great an incompatibility. (See Mandy's comment[5] for > more.) > > So the proposal is to revert the JDK-8212117 change, along with a > couple follow-up tasks: > > * Update the Class::forName API spec to match the long-standing > behavior (i.e. no linking if initialize=false) - JDK-8233272 [6] > > * Reopen JDK-8181144[7] for further investigation of JDI > VirtualMachine::allClasses and JVM TI AllLoadedClasses > > Thanks, > -Brent > > ============== > 1. https://bugs.openjdk.java.net/browse/JDK-8212117 > > 2. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062142.html > > 3. > https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader) > > 4. https://bugs.openjdk.java.net/browse/JDK-8231924 > > 5. > https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14297501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14297501 > > 6. https://bugs.openjdk.java.net/browse/JDK-8233272 > > 7. https://bugs.openjdk.java.net/browse/JDK-8181144 > >