From kim.barrett at oracle.com Sat Aug 1 09:14:24 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 1 Aug 2020 05:14:24 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: > On Jul 31, 2020, at 11:43 AM, coleen.phillimore at oracle.com wrote: > > > Markus contributed a better incremental patch on top of this, please review tested 02 patch instead. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02/webrev > > Thanks, > Coleen > > On 7/31/20 10:16 AM, coleen.phillimore at oracle.com wrote: >> Summary: Add a weak OopStorage for JFR and move the oops there. Remove GC code to process oops. >> >> Tested with tier1,5, and 6. Built with shenandoah. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8235573 >> >> Thanks, >> Coleen One less serial weak processing phase! Yay! ------------------------------------------------------------------------------ src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp 66 if (!_dead_samples) { 67 _dead_samples = true; 68 } else { 69 // Need exclusive access to avoid a race that could loose a 70 // notification about new dead samples. Previously, the notification 71 // happened during a safepoint, i.e. as part of weak_oops_do(), 72 // but with the change to OopStorage, it can happen concurrently 73 // with threads trying to reset the flag. 74 acquire(); 75 _dead_samples = true; 76 release(); 77 } _dead_samples is potentially accessed by multiple threads, including writers. That suggests it needs to be an "atomic" variable. Blocking on a potentially long-duration (spin!) lock in this gc-callback might be a problem. The approach taken by the string table might be better. There is a similar race there. The approach taken there is to just lose the race and let the next GC trigger cleanup. But StringTable also uses another thread (the ServiceThread) to perform the cleanup, rather than piggy-backing cleanup on the add() operation, which might not occur at an appropriately timed point. I think a structure similar to that used by the StringTable would work well here too. A different approach would be to have the gc-callback unconditionally set _dead_samples if any are reported, and have scavenge clear _dead_samples before doing its cleanup. But that can result in back-to-back cleanups (by successive adds) where the second might not be needed. The StringTable approach prefers a possibly delayed cleanup vs unnecessary cleanups. And it seems a delayed cleanup is acceptable here, since it won't even be considered until an add operation following _dead_samples being set. ------------------------------------------------------------------------------ src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp 100 _size(size) { 101 _last_sweep = JfrTicks::now(); 102 _dead_samples = false; 103 } Assignments in the body are mis-indented. But why were they changed from mem-initializers to assignments? ------------------------------------------------------------------------------ Including "Weak" in the oopstorage's name would be consistent with the others, and makes things a little more obvious in GC logs. From Charlie.Gracie at microsoft.com Sat Aug 1 15:27:16 2020 From: Charlie.Gracie at microsoft.com (Charlie Gracie) Date: Sat, 1 Aug 2020 15:27:16 +0000 Subject: Scoping the stack allocation prototype for C2 Message-ID: Hi Richard, Yeah this will be a fun experiment and we are optimistic about the possible improvements. We gathered data for the benchmarks and workloads that are showing the biggest wins with the stack allocation prototype. The majority of the wins are in heavy allocating loops. Assuming we can hoist most of the allocations in loops that were eligible to be stack allocated this should realize a majority of the wins. By allowing ArgEscape, whenever possible, and removing the current constraints in compressed oops mode for stack allocation we are excited to see how it performs. Also, I think this work leads very nicely into the zone-based allocation investigation. I expect there will still be some wins to be had and it is another fun experiment to look into. Cheers, Charlie ?On 2020-07-31, 11:09 AM, "Reingruber, Richard" wrote: Hi Nikola, hi Charlie, thanks for spending the effort and doing the experiment. Actually I think it's fun to do :) Hoisting allocations probably won't be as effective as stack allocation, but doing it for ArgEscape allocations, too, (if feasable) will likely help. Thanks, Richard. -----Original Message----- From: Nikola Grcevski Sent: Freitag, 31. Juli 2020 15:44 To: Reingruber, Richard ; Charlie Gracie ; Erik ?sterlund ; hotspot-dev Source Developers Subject: RE: Re: Scoping the stack allocation prototype for C2 Hi Richard, Thanks for your suggestion. We have started looking at this and once we have the allocation hoisting prototype ready, we'll measure it against what we get with the stack allocation patch. Once we have some results we'll share them here. We are open to more suggestions from you or anyone else in the community. Thanks, Nikola and Charlie -----Original Message----- From: Reingruber, Richard Sent: July 29, 2020 3:52 AM To: Charlie Gracie ; Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: RE: Re: Scoping the stack allocation prototype for C2 Hi, an even simpler optimization could be to find allocations that don't escape a loop body, schedule them into a dominating region and reuse the allocated bytes in the loop body. This would be possible without special allocation zones/buffers. At first glance this seems to be comparatively simple, but still effective. Again a lot would depend on inlining: will hot allocations be compiled together with their loop? And I'd think that there have to be hot allocations in the benchmark for stack allocation to be beneficial. If they are not hot then young gen allocation/reclamation are probably good enough. Maybe the allocation could even be undone after the loop if there was no escaping allocation in the loop. I guess this is the downside: no implicit free when the compiled method returns. Best regards, Richard. -----Original Message----- From: hotspot-dev On Behalf Of Charlie Gracie Sent: Montag, 27. Juli 2020 21:24 To: Erik ?sterlund ; Nikola Grcevski ; hotspot-dev Source Developers Subject: Re: Re: Scoping the stack allocation prototype for C2 Hi Erik, > It sounds like the high level goal is not "allocate on the stack", but > rather allocate and free objects more efficiently based on compile-time knowledge about their scoped lifetime. Yes, you are correct. That is the best way to describe our high-level goal. > Since I can see so many advantages with this approach, and not really > any disadvantages if done right, I wonder if there are any clear > reasons not to build it in that (general) way instead.I am curious to hear your thoughts about this. > > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. > But maybe we should settle on the direction first instead.Perhaps > there are some nice quirks with stack allocations that still make them more desirable, even though I can not currently see it. You have made excellent points about the pros and cons of both solutions, along with Vladimir and others. Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach. > If you agree this is probably a better way of achieving the same > thing, then I have some ideas how best to implement it that we could discuss. We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. Thanks again for your insightful comments, Charlie & Nikola From david.holmes at oracle.com Mon Aug 3 04:15:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Aug 2020 14:15:42 +1000 Subject: RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 In-Reply-To: References: Message-ID: <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> Hi Bernhard, On 30/07/2020 10:59 pm, Bernhard Urban-Forster wrote: > Hi all, > > the original change [1] missed to update an assert. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8250824 > Webrev: http://cr.openjdk.java.net/~burban/8250824/ Looks good and trivial. I will sponsor for you. David ----- > > Thank you, > -Bernhard > > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/d352e5db468c > From beurba at microsoft.com Mon Aug 3 07:53:11 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 3 Aug 2020 07:53:11 +0000 Subject: RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 In-Reply-To: <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> References: , <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> Message-ID: Thank you David! -Bernhard ________________________________________ From: David Holmes Sent: Monday, August 3, 2020 06:15 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 Hi Bernhard, On 30/07/2020 10:59 pm, Bernhard Urban-Forster wrote: > Hi all, > > the original change [1] missed to update an assert. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250824&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581093986&sdata=7%2BasxpoTHgssuQ2%2BKsWbPOHJXToT2rD4YZSBIVwHiVQ%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8250824%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581093986&sdata=gYwzMY7aYc4cNqCCgMZ0gn060rLtpRR5n1CI4V9I7F0%3D&reserved=0 Looks good and trivial. I will sponsor for you. David ----- > > Thank you, > -Bernhard > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2Fd352e5db468c&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581103985&sdata=dncJ0%2BZUwMFk243t6H2QrSAg%2FBFGlgJwRSCn75Ghfck%3D&reserved=0 > From coleen.phillimore at oracle.com Mon Aug 3 13:14:27 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 3 Aug 2020 09:14:27 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: Kim, Thank you for reading this change. On 8/1/20 5:14 AM, Kim Barrett wrote: >> On Jul 31, 2020, at 11:43 AM, coleen.phillimore at oracle.com wrote: >> >> >> Markus contributed a better incremental patch on top of this, please review tested 02 patch instead. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02/webrev >> >> Thanks, >> Coleen >> >> On 7/31/20 10:16 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Add a weak OopStorage for JFR and move the oops there. Remove GC code to process oops. >>> >>> Tested with tier1,5, and 6. Built with shenandoah. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8235573 >>> >>> Thanks, >>> Coleen > One less serial weak processing phase! Yay! We thought you'd like that.? Unfortunately, the jvmti serial phase is hard to eradicate. > > ------------------------------------------------------------------------------ > src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp > 66 if (!_dead_samples) { > 67 _dead_samples = true; > 68 } else { > 69 // Need exclusive access to avoid a race that could loose a > 70 // notification about new dead samples. Previously, the notification > 71 // happened during a safepoint, i.e. as part of weak_oops_do(), > 72 // but with the change to OopStorage, it can happen concurrently > 73 // with threads trying to reset the flag. > 74 acquire(); > 75 _dead_samples = true; > 76 release(); > 77 } > > _dead_samples is potentially accessed by multiple threads, including > writers. That suggests it needs to be an "atomic" variable. > > Blocking on a potentially long-duration (spin!) lock in this gc-callback > might be a problem. The approach taken by the string table might be better. > There is a similar race there. The approach taken there is to just lose the > race and let the next GC trigger cleanup. But StringTable also uses another > thread (the ServiceThread) to perform the cleanup, rather than piggy-backing > cleanup on the add() operation, which might not occur at an appropriately > timed point. > > I think a structure similar to that used by the StringTable would work well > here too. > > A different approach would be to have the gc-callback unconditionally set > _dead_samples if any are reported, and have scavenge clear _dead_samples > before doing its cleanup. But that can result in back-to-back cleanups > (by successive adds) where the second might not be needed. The StringTable > approach prefers a possibly delayed cleanup vs unnecessary cleanups. And > it seems a delayed cleanup is acceptable here, since it won't even be > considered until an add operation following _dead_samples being set. Markus and I talked about this and since the lists are generally short and the race is very unlikely, having back-to-back GCs is a problem that this can live with.? I'd hate to see the JFR code spashed into the ServiceThread mechanism for this race. I've also made all the _dead_samples accesses atomic, and set it unconditionally in the gc_notification. > > ------------------------------------------------------------------------------ > src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp > 100 _size(size) { > 101 _last_sweep = JfrTicks::now(); > 102 _dead_samples = false; > 103 } > > Assignments in the body are mis-indented. But why were they changed from > mem-initializers to assignments? _last_sweep and _dead_samples are statics now, so aren't mem initializers. I fixed the indentation. > > ------------------------------------------------------------------------------ > > Including "Weak" in the oopstorage's name would be consistent with the > others, and makes things a little more obvious in GC logs. > > Fixes this too. incremental webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev full webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev And retested. Thanks, Coleen From david.holmes at oracle.com Mon Aug 3 23:25:56 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Aug 2020 09:25:56 +1000 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> Hi Coleen, On 3/08/2020 11:14 pm, coleen.phillimore at oracle.com wrote: > > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev src/hotspot/share/gc/shared/weakProcessorPhases.hpp Have you built this with JVMTI disabled? I'm not sure if an empty enum declaration might produce a warning? --- src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp Are there any ordering constraints on these store pairs: 68 Atomic::store(&_dead_samples, true); 69 _last_sweep = JfrTicks::now(); 93 _last_sweep = JfrTicks::now(); 94 Atomic::store(&_dead_samples, false); ? --- Otherwise this all seems good. Thanks, David ----- > And retested. > Thanks, > Coleen > From kim.barrett at oracle.com Tue Aug 4 05:44:35 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 4 Aug 2020 01:44:35 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> Message-ID: > On Aug 3, 2020, at 9:14 AM, coleen.phillimore at oracle.com wrote: > On 8/1/20 5:14 AM, Kim Barrett wrote: >> One less serial weak processing phase! Yay! > > We thought you'd like that. Unfortunately, the jvmti serial phase is hard to eradicate. I had an idea for that a long time ago, but haven?t followed up. > incremental webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev > full webrev at http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev _last_sweep is being written by one thread and read others. For STW reference processing collectors this might not be a problem; I'm not sure what threads do the reading and what their state is when the read is performed. But even if that's the case, this seems like it should a be a problem for concurrent reference processing. > And retested. > Thanks, > Coleen From thomas.schatzl at oracle.com Tue Aug 4 08:00:57 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 4 Aug 2020 10:00:57 +0200 Subject: RFR: 8250652: Add logical operations on types In-Reply-To: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> References: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> Message-ID: <0d3c280e-035c-dd60-6d07-f6cd55457d4d@oracle.com> Hi, On 28.07.20 14:34, Kim Barrett wrote: > Please review this change which adds metafunctions for performing > logical operations on types. These are based on facilities provided > by C++17, but which can be useful before we are using that version of > the language standard. (I already have some in-development changes > that use some of them.) > > I've not provided stand-ins for the associated template variables, > since template variables are not yet on the list approved for use in > HotSpot. They can easily be added later if desired. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8250652 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8250652/open.00/ > > Testing: > tier1 > > lgtm. May I ask what these in-development changes are about? Thanks, Thomas From kim.barrett at oracle.com Tue Aug 4 08:16:43 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 4 Aug 2020 04:16:43 -0400 Subject: RFR: 8250652: Add logical operations on types In-Reply-To: <0d3c280e-035c-dd60-6d07-f6cd55457d4d@oracle.com> References: <7B7D96F2-212F-4842-A4A9-F2F2C1B521C5@oracle.com> <0d3c280e-035c-dd60-6d07-f6cd55457d4d@oracle.com> Message-ID: <1668CE6C-A2A1-4831-BF58-E88D0FD518FF@oracle.com> > On Aug 4, 2020, at 4:00 AM, Thomas Schatzl wrote: > > Hi, > > On 28.07.20 14:34, Kim Barrett wrote: >> Please review this change which adds metafunctions for performing >> logical operations on types. These are based on facilities provided >> by C++17, but which can be useful before we are using that version of >> the language standard. (I already have some in-development changes >> that use some of them.) >> I've not provided stand-ins for the associated template variables, >> since template variables are not yet on the list approved for use in >> HotSpot. They can easily be added later if desired. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8250652 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8250652/open.00/ >> Testing: >> tier1 > > lgtm. May I ask what these in-development changes are about? > > Thanks, > Thomas Thanks. Additional metaprogramming tools that simplify function template SFINAE control, which I then intend to use for things like JDK-8247909, JDK-8247910, and an as-yet unfiled RFE to do some similar things for Access operations (after another as-yet unfiled RFE to make Access decorators type-safe using scoped enums). From markus.gronlund at oracle.com Tue Aug 4 09:39:00 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 4 Aug 2020 02:39:00 -0700 (PDT) Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> Message-ID: <8058cd63-55d8-41bb-b776-c88b4e86831b@default> Hello, About _last_sweep: The value, representing the last time the GC passed over the sample instances, is only treated as a hint, used as input to construct a filter when serializing object samples as events along with their associated chains. The filter excludes samples that are short-lived, i.e. having timestamps after the _last_sweep value. _last_sweep is only read by a single thread which at that moment have exclusive access to the sampler instance. It is ok for it to read whatever value leaked to it, in fact it can be advantageous to see an older value as it makes the filter more effective in reducing noise. Therefore, I think it is ok to leave an undecorated access to this variable. Also, there is no ordering constraint, the value is just reset when constructing a new instance, and a race is ok here too. Thanks Markus -----Original Message----- From: David Holmes Sent: den 4 augusti 2020 01:26 To: Coleen Phillimore ; Kim Barrett Cc: hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage Hi Coleen, On 3/08/2020 11:14 pm, coleen.phillimore at oracle.com wrote: > > incremental webrev at > http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev > full webrev at > http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev src/hotspot/share/gc/shared/weakProcessorPhases.hpp Have you built this with JVMTI disabled? I'm not sure if an empty enum declaration might produce a warning? --- src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp Are there any ordering constraints on these store pairs: 68 Atomic::store(&_dead_samples, true); 69 _last_sweep = JfrTicks::now(); 93 _last_sweep = JfrTicks::now(); 94 Atomic::store(&_dead_samples, false); ? --- Otherwise this all seems good. Thanks, David ----- > And retested. > Thanks, > Coleen > From david.holmes at oracle.com Tue Aug 4 10:56:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Aug 2020 20:56:57 +1000 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <8058cd63-55d8-41bb-b776-c88b4e86831b@default> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> Message-ID: <90a9f44e-2208-a99c-1048-034dfe7d7da4@oracle.com> Hi Markus, On 4/08/2020 7:39 pm, Markus Gronlund wrote: > Hello, > > About _last_sweep: > > The value, representing the last time the GC passed over the sample instances, is only treated as a hint, used as input to construct a filter when serializing object samples as events along with their associated chains. The filter excludes samples that are short-lived, i.e. having timestamps after the _last_sweep value. _last_sweep is only read by a single thread which at that moment have exclusive access to the sampler instance. It is ok for it to read whatever value leaked to it, in fact it can be advantageous to see an older value as it makes the filter more effective in reducing noise. Therefore, I think it is ok to leave an undecorated access to this variable. Also, there is no ordering constraint, the value is just reset when constructing a new instance, and a race is ok here too. Thanks for clarifying that. David > Thanks > Markus > > -----Original Message----- > From: David Holmes > Sent: den 4 augusti 2020 01:26 > To: Coleen Phillimore ; Kim Barrett > Cc: hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net > Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage > > Hi Coleen, > > On 3/08/2020 11:14 pm, coleen.phillimore at oracle.com wrote: > >> >> incremental webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev >> full webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev > > src/hotspot/share/gc/shared/weakProcessorPhases.hpp > > Have you built this with JVMTI disabled? I'm not sure if an empty enum declaration might produce a warning? > > --- > > src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp > > Are there any ordering constraints on these store pairs: > > 68 Atomic::store(&_dead_samples, true); > 69 _last_sweep = JfrTicks::now(); > > 93 _last_sweep = JfrTicks::now(); > 94 Atomic::store(&_dead_samples, false); > > ? > > --- > > Otherwise this all seems good. > > Thanks, > David > ----- > > >> And retested. >> Thanks, >> Coleen >> From coleen.phillimore at oracle.com Tue Aug 4 11:05:36 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 4 Aug 2020 07:05:36 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <90a9f44e-2208-a99c-1048-034dfe7d7da4@oracle.com> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> <90a9f44e-2208-a99c-1048-034dfe7d7da4@oracle.com> Message-ID: <6efea619-3363-8795-355b-ab282235cfcb@oracle.com> On 8/4/20 6:56 AM, David Holmes wrote: > Hi Markus, > > On 4/08/2020 7:39 pm, Markus Gronlund wrote: >> Hello, >> >> About _last_sweep: >> >> The value, representing the last time the GC passed over the sample >> instances, is only treated as a hint, used as input to construct a >> filter when serializing object samples as events along with their >> associated chains. The filter excludes samples that are short-lived, >> i.e. having timestamps after the _last_sweep value. _last_sweep is >> only read by a single thread which at that moment have exclusive >> access to the sampler instance. It is ok for it to read whatever >> value leaked to it, in fact it can be advantageous to see an older >> value as it makes the filter more effective in reducing noise. >> Therefore, I think it is ok to leave an undecorated access to this >> variable. Also, there is no ordering constraint, the value is just >> reset when constructing a new instance, and a race is ok here too. > > Thanks for clarifying that. Yes, thank you Markus. Coleen > > David > >> Thanks >> Markus >> >> -----Original Message----- >> From: David Holmes >> Sent: den 4 augusti 2020 01:26 >> To: Coleen Phillimore ; Kim Barrett >> >> Cc: hotspot-dev developers ; >> hotspot-jfr-dev at openjdk.java.net >> Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage >> >> Hi Coleen, >> >> On 3/08/2020 11:14 pm, coleen.phillimore at oracle.com wrote: >> >>> >>> incremental webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8235573.02.incr/webrev >>> full webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8235573.03/webrev >> >> src/hotspot/share/gc/shared/weakProcessorPhases.hpp >> >> Have you built this with JVMTI disabled? I'm not sure if an empty >> enum declaration might produce a warning? >> >> --- >> >> src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp >> >> Are there any ordering constraints on these store pairs: >> >> ?? 68???? Atomic::store(&_dead_samples, true); >> ?? 69???? _last_sweep = JfrTicks::now(); >> >> ?? 93?? _last_sweep = JfrTicks::now(); >> ?? 94?? Atomic::store(&_dead_samples, false); >> >> ? >> >> --- >> >> Otherwise this all seems good. >> >> Thanks, >> David >> ----- >> >> >>> And retested. >>> Thanks, >>> Coleen >>> From vladimir.kozlov at oracle.com Tue Aug 4 19:52:29 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Aug 2020 12:52:29 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: Hi Vladimir, Looks good. I have only few small questions. compile.cpp: what is next comment about? + // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack. print_method(): NodeClassNames[] should be available in product. Node::Name() method is not, but we can move it to product. But I am fine to do that later. Why VectorSupport.java does not have copyright header? Thanks, Vladimir K On 7/28/20 3:29 PM, Vladimir Ivanov wrote: > Hi, > > Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! > > Here are the latest changes for Vector API support in HotSpot shared code: > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 > > Incremental changes (diff against webrev.00): > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 > > I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor > cleanups / simple bug fixes. > > Detailed summary: > ? - rebased to jdk/jdk tip; > ? - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > ? - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); > ? - got rid of x86-specific changes in shared code; > ? - fix for 8244867 [1]; > ? - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics > ? - numerous minor cleanups > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 > ??? http://jbs.oracle.com/browse/JDK-8244867 > ??? 8244867: 2 vector api tests crash with assert(is_reference_type(basic_type())) failed: wrong type > Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. > > On 04.04.2020 02:12, Vladimir Ivanov wrote: >> Hi, >> >> Following up on review requests of API [0] and Java implementation [1] for Vector API (JEP 338 [2]), here's a request >> for review of general HotSpot changes (in shared code) required for supporting the API: >> >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ >> >> (First of all, to set proper expectations: since the JEP is still in Candidate state, the intention is to initiate >> preliminary round(s) of review to inform the community and gather feedback before sending out final/official RFRs once >> the JEP is Targeted to a release.) >> >> Vector API (being developed in Project Panama [3]) relies on JVM support to utilize optimal vector hardware >> instructions at runtime. It interacts with JVM through intrinsics (declared in jdk.internal.vm.vector.VectorSupport >> [4]) which expose vector operations support in C2 JIT-compiler. >> >> As Paul wrote earlier: "A vector intrinsic is an internal low-level vector operation. The last argument to the >> intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the >> vector.? Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is >> executed (the Java implementation is always executed when running in the interpreter or for C1)." >> >> The rest of JVM support is about aggressively optimizing vector boxes to minimize (ideally eliminate) the overhead of >> boxing for vector values. >> It's a stop-the-gap solution for vector box elimination problem until inline classes arrive. Vector classes are >> value-based and in the longer term will be migrated to inline classes once the support becomes available. >> >> Vector API talk from JVMLS'18 [5] contains brief overview of JVM implementation and some details. >> >> Complete implementation resides in vector-unstable branch of panama/dev repository [6]. >> >> Now to gory details (the patch is split in multiple "sub-webrevs"): >> >> =========================================================== >> >> (1) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ >> >> Ideal vector nodes for new operations introduced by Vector API. >> >> (Platform-specific back end support will be posted for review separately). >> >> =========================================================== >> >> (2) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ >> >> JVM Java interface (VectorSupport) and intrinsic support in C2. >> >> Vector instances are initially represented as VectorBox macro nodes and "unboxing" is represented by VectorUnbox node. >> It simplifies vector box elimination analysis and the nodes are expanded later right before EA pass. >> >> Vectors have 2-level on-heap representation: for the vector value primitive array is used as a backing storage and it >> is encapsulated in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a int[8] instance which is used >> to store vector value). >> >> Unless VectorBox node goes away, it needs to be expanded into an allocation eventually, but it is a pure node and >> doesn't have any JVM state associated with it. The problem is solved by keeping JVM state separately in a >> VectorBoxAllocate node associated with VectorBox node and use it during expansion. >> >> Also, to simplify vector box elimination, inlining of vector reboxing calls (VectorSupport::maybeRebox) is delayed >> until the analysis is over. >> >> =========================================================== >> >> (3) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ >> >> Vector box elimination analysis implementation. (Brief overview: slides #36-42 [5].) >> >> The main part is devoted to scalarization across safepoints and rematerialization support during deoptimization. In >> C2-generated code vector operations work with raw vector values which live in registers or spilled on the stack and it >> allows to avoid boxing/unboxing when a vector value is alive across a safepoint. As with other values, there's just a >> location of the vector value at the safepoint and vector type information recorded in the relevant nmethod metadata >> and all the heavy-lifting happens only when rematerialization takes place. >> >> The analysis preserves object identity invariants except during aggressive reboxing (guarded by >> -XX:+EnableAggressiveReboxing). >> >> (Aggressive reboxing is crucial for cases when vectors "escape": it allocates a fresh instance at every escape point >> thus enabling original instance to go away.) >> >> =========================================================== >> >> (4) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ >> >> HotSpot changes for jdk.incubator.vector module. Vector support is makred experimental and turned off by default. JEP >> 338 proposes the API to be released as an incubator module, so a user has to specify "--add-module >> jdk.incubator.vector" on the command line to be able to use it. >> When user does that, JVM automatically enables Vector API support. >> It improves usability (user doesn't need to separately "open" the API and enable JVM support) while minimizing risks >> of destabilitzation from new code when the API is not used. >> >> >> That's it! Will be happy to answer any questions. >> >> And thanks in advance for any feedback! >> >> Best regards, >> Vladimir Ivanov >> >> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html >> >> [2] https://openjdk.java.net/jeps/338 >> >> [3] https://openjdk.java.net/projects/panama/ >> >> [4] >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html >> >> >> [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >> >> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >> >> ???? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From vladimir.kozlov at oracle.com Tue Aug 4 19:59:52 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Aug 2020 12:59:52 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: x86 changes seems fine. Thanks, Vladimir K On 7/29/20 11:19 AM, Viswanathan, Sandhya wrote: > Hi, > > Likewise, the corresponding x86 backend changes since first review are also only minor cleanups and simple bug fixes: > > X86: > Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.01/ > Incremental: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00-webrev.01/ > > Summary: > - rebased to jdk/jdk tip; > - backend changes related to removal of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > - vector insert bug fix > - some minor cleanups > > Older webrev links for your reference: > X86b backend: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Ivanov > Sent: Tuesday, July 28, 2020 3:30 PM > To: hotspot-dev ; hotspot compiler > Cc: Viswanathan, Sandhya ; panama-dev > Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes > > Hi, > > Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! > > Here are the latest changes for Vector API support in HotSpot shared code: > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 > > Incremental changes (diff against webrev.00): > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 > > I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor cleanups / simple bug fixes. > > Detailed summary: > - rebased to jdk/jdk tip; > - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); > - got rid of x86-specific changes in shared code; > - fix for 8244867 [1]; > - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics > - numerous minor cleanups > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 > http://jbs.oracle.com/browse/JDK-8244867 > 8244867: 2 vector api tests crash with > assert(is_reference_type(basic_type())) failed: wrong type > Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. > > On 04.04.2020 02:12, Vladimir Ivanov wrote: >> Hi, >> >> Following up on review requests of API [0] and Java implementation [1] >> for Vector API (JEP 338 [2]), here's a request for review of general >> HotSpot changes (in shared code) required for supporting the API: >> >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/all.00-03/ >> >> >> (First of all, to set proper expectations: since the JEP is still in >> Candidate state, the intention is to initiate preliminary round(s) of >> review to inform the community and gather feedback before sending out >> final/official RFRs once the JEP is Targeted to a release.) >> >> Vector API (being developed in Project Panama [3]) relies on JVM >> support to utilize optimal vector hardware instructions at runtime. It >> interacts with JVM through intrinsics (declared in >> jdk.internal.vm.vector.VectorSupport [4]) which expose vector >> operations support in C2 JIT-compiler. >> >> As Paul wrote earlier: "A vector intrinsic is an internal low-level >> vector operation. The last argument to the intrinsic is fall back >> behavior in Java, implementing the scalar operation over the number of >> elements held by the vector.? Thus, If the intrinsic is not supported >> in >> C2 for the other arguments then the Java implementation is executed >> (the Java implementation is always executed when running in the >> interpreter or for C1)." >> >> The rest of JVM support is about aggressively optimizing vector boxes >> to minimize (ideally eliminate) the overhead of boxing for vector values. >> It's a stop-the-gap solution for vector box elimination problem until >> inline classes arrive. Vector classes are value-based and in the >> longer term will be migrated to inline classes once the support becomes available. >> >> Vector API talk from JVMLS'18 [5] contains brief overview of JVM >> implementation and some details. >> >> Complete implementation resides in vector-unstable branch of >> panama/dev repository [6]. >> >> Now to gory details (the patch is split in multiple "sub-webrevs"): >> >> =========================================================== >> >> (1) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/00.backend.shared/ >> >> >> Ideal vector nodes for new operations introduced by Vector API. >> >> (Platform-specific back end support will be posted for review separately). >> >> =========================================================== >> >> (2) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/01.intrinsics/ >> >> >> JVM Java interface (VectorSupport) and intrinsic support in C2. >> >> Vector instances are initially represented as VectorBox macro nodes >> and "unboxing" is represented by VectorUnbox node. It simplifies >> vector box elimination analysis and the nodes are expanded later right before EA pass. >> >> Vectors have 2-level on-heap representation: for the vector value >> primitive array is used as a backing storage and it is encapsulated in >> a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a >> int[8] instance which is used to store vector value). >> >> Unless VectorBox node goes away, it needs to be expanded into an >> allocation eventually, but it is a pure node and doesn't have any JVM >> state associated with it. The problem is solved by keeping JVM state >> separately in a VectorBoxAllocate node associated with VectorBox node >> and use it during expansion. >> >> Also, to simplify vector box elimination, inlining of vector reboxing >> calls (VectorSupport::maybeRebox) is delayed until the analysis is over. >> >> =========================================================== >> >> (3) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/02.vbox_elimination/ >> >> >> Vector box elimination analysis implementation. (Brief overview: >> slides >> #36-42 [5].) >> >> The main part is devoted to scalarization across safepoints and >> rematerialization support during deoptimization. In C2-generated code >> vector operations work with raw vector values which live in registers >> or spilled on the stack and it allows to avoid boxing/unboxing when a >> vector value is alive across a safepoint. As with other values, >> there's just a location of the vector value at the safepoint and >> vector type information recorded in the relevant nmethod metadata and >> all the heavy-lifting happens only when rematerialization takes place. >> >> The analysis preserves object identity invariants except during >> aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). >> >> (Aggressive reboxing is crucial for cases when vectors "escape": it >> allocates a fresh instance at every escape point thus enabling >> original instance to go away.) >> >> =========================================================== >> >> (4) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/03.module.hotspot/ >> >> >> HotSpot changes for jdk.incubator.vector module. Vector support is >> makred experimental and turned off by default. JEP 338 proposes the >> API to be released as an incubator module, so a user has to specify >> "--add-module jdk.incubator.vector" on the command line to be able to >> use it. >> When user does that, JVM automatically enables Vector API support. >> It improves usability (user doesn't need to separately "open" the API >> and enable JVM support) while minimizing risks of destabilitzation >> from new code when the API is not used. >> >> >> That's it! Will be happy to answer any questions. >> >> And thanks in advance for any feedback! >> >> Best regards, >> Vladimir Ivanov >> >> [0] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/06534 >> 5.html >> >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228. >> html >> >> [2] https://openjdk.java.net/jeps/338 >> >> [3] https://openjdk.java.net/projects/panama/ >> >> [4] >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar >> ed/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm >> /vector/VectorSupport.java.html >> >> >> [5] >> http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >> >> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >> >> ??? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b >> vector-unstable From igor.ignatyev at oracle.com Tue Aug 4 23:58:48 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 4 Aug 2020 16:58:48 -0700 Subject: RFR(S) : 8251126 : nsk.share.GoldChecker should read golden file from ${test.src} Message-ID: <7510EC68-7A8C-4F1E-A928-5910F13FA5D9@oracle.com> http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ > 37 lines changed: 7 ins; 20 del; 10 mod; Hi all, could you please review this patch? from JBS: > as of now, nsk.share.GoldChecker reads golden files from the current directory, which makes it necessary to copy golden files from ${test.src} before the execution of the tests which use GoldChecker. after this patch, FileInstaller actions will become redundant in 103 of :vmTestbase_vm_compiler tests and will be removed by 8251127. JBS: https://bugs.openjdk.java.net/browse/JDK-8251126 webrev: http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ testing: :vmTestbase_vm_compiler tests 8251127: https://bugs.openjdk.java.net/browse/JDK-8251127 Thanks, -- Igor From igor.ignatyev at oracle.com Tue Aug 4 23:59:32 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 4 Aug 2020 16:59:32 -0700 Subject: RFR(L/S) : 8249030 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdi tests In-Reply-To: <637D6495-24E6-4874-9024-1B0082492085@oracle.com> References: <637D6495-24E6-4874-9024-1B0082492085@oracle.com> Message-ID: ping? -- Igor > On Jul 31, 2020, at 1:24 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00 >> 2258 lines changed: 0 ins; 1144 del; 1114 mod; > > Hi all, > > could you please review the clean-up of nsk_jdi tests? > from main issue(8204985) : >> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. > > > the patch removes FileInstaller actions in the said tests, and as before, the biggest part of patch was done by `ag -l '@run driver jdk.test.lib.FileInstaller . .' $DIR | xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}` with $DIR being test/hotspot/jtreg/vmTestbase/nsk/jdi/. > > the 10 tests which had '-configFile ./<...>', and hence were looking for config file in the current directory, were updated to search for a config file in 'test.src' directory: http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00-configFile > > testing: :vmTestbase_nsk_jdi on {linux,windows,macos}-x64 > JBS: https://bugs.openjdk.java.net/browse/JDK-8249030 > webrev: http://cr.openjdk.java.net/~iignatyev/8249030/webrev.00/ > > Thanks, > -- Igor From sandhya.viswanathan at intel.com Wed Aug 5 00:16:44 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 5 Aug 2020 00:16:44 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: Thanks a lot for the review. Best Regards, Sandhya -----Original Message----- From: Vladimir Kozlov Sent: Tuesday, August 04, 2020 1:00 PM To: Viswanathan, Sandhya ; Vladimir Ivanov ; hotspot-dev ; hotspot compiler Cc: panama-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes x86 changes seems fine. Thanks, Vladimir K On 7/29/20 11:19 AM, Viswanathan, Sandhya wrote: > Hi, > > Likewise, the corresponding x86 backend changes since first review are also only minor cleanups and simple bug fixes: > > X86: > Full: http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.01/ > Incremental: > http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00 > -webrev.01/ > > Summary: > - rebased to jdk/jdk tip; > - backend changes related to removal of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > - vector insert bug fix > - some minor cleanups > > Older webrev links for your reference: > X86b backend: > http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00 > / > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Ivanov > Sent: Tuesday, July 28, 2020 3:30 PM > To: hotspot-dev ; hotspot compiler > > Cc: Viswanathan, Sandhya ; panama-dev > > Subject: Re: RFR (XXL): 8223347: Integration of Vector API > (Incubator): General HotSpot changes > > Hi, > > Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! > > Here are the latest changes for Vector API support in HotSpot shared code: > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.01 > > Incremental changes (diff against webrev.00): > > http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shar > ed/webrev.01_00 > > I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor cleanups / simple bug fixes. > > Detailed summary: > - rebased to jdk/jdk tip; > - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; > - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); > - got rid of x86-specific changes in shared code; > - fix for 8244867 [1]; > - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics > - numerous minor cleanups > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 > http://jbs.oracle.com/browse/JDK-8244867 > 8244867: 2 vector api tests crash with > assert(is_reference_type(basic_type())) failed: wrong type > Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. > > On 04.04.2020 02:12, Vladimir Ivanov wrote: >> Hi, >> >> Following up on review requests of API [0] and Java implementation >> [1] for Vector API (JEP 338 [2]), here's a request for review of >> general HotSpot changes (in shared code) required for supporting the API: >> >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/all.00-03/ >> >> >> (First of all, to set proper expectations: since the JEP is still in >> Candidate state, the intention is to initiate preliminary round(s) of >> review to inform the community and gather feedback before sending out >> final/official RFRs once the JEP is Targeted to a release.) >> >> Vector API (being developed in Project Panama [3]) relies on JVM >> support to utilize optimal vector hardware instructions at runtime. >> It interacts with JVM through intrinsics (declared in >> jdk.internal.vm.vector.VectorSupport [4]) which expose vector >> operations support in C2 JIT-compiler. >> >> As Paul wrote earlier: "A vector intrinsic is an internal low-level >> vector operation. The last argument to the intrinsic is fall back >> behavior in Java, implementing the scalar operation over the number >> of elements held by the vector.? Thus, If the intrinsic is not >> supported in >> C2 for the other arguments then the Java implementation is executed >> (the Java implementation is always executed when running in the >> interpreter or for C1)." >> >> The rest of JVM support is about aggressively optimizing vector boxes >> to minimize (ideally eliminate) the overhead of boxing for vector values. >> It's a stop-the-gap solution for vector box elimination problem until >> inline classes arrive. Vector classes are value-based and in the >> longer term will be migrated to inline classes once the support becomes available. >> >> Vector API talk from JVMLS'18 [5] contains brief overview of JVM >> implementation and some details. >> >> Complete implementation resides in vector-unstable branch of >> panama/dev repository [6]. >> >> Now to gory details (the patch is split in multiple "sub-webrevs"): >> >> =========================================================== >> >> (1) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/00.backend.shared/ >> >> >> Ideal vector nodes for new operations introduced by Vector API. >> >> (Platform-specific back end support will be posted for review separately). >> >> =========================================================== >> >> (2) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/01.intrinsics/ >> >> >> JVM Java interface (VectorSupport) and intrinsic support in C2. >> >> Vector instances are initially represented as VectorBox macro nodes >> and "unboxing" is represented by VectorUnbox node. It simplifies >> vector box elimination analysis and the nodes are expanded later right before EA pass. >> >> Vectors have 2-level on-heap representation: for the vector value >> primitive array is used as a backing storage and it is encapsulated >> in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains >> a int[8] instance which is used to store vector value). >> >> Unless VectorBox node goes away, it needs to be expanded into an >> allocation eventually, but it is a pure node and doesn't have any JVM >> state associated with it. The problem is solved by keeping JVM state >> separately in a VectorBoxAllocate node associated with VectorBox node >> and use it during expansion. >> >> Also, to simplify vector box elimination, inlining of vector reboxing >> calls (VectorSupport::maybeRebox) is delayed until the analysis is over. >> >> =========================================================== >> >> (3) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/02.vbox_elimination/ >> >> >> Vector box elimination analysis implementation. (Brief overview: >> slides >> #36-42 [5].) >> >> The main part is devoted to scalarization across safepoints and >> rematerialization support during deoptimization. In C2-generated code >> vector operations work with raw vector values which live in registers >> or spilled on the stack and it allows to avoid boxing/unboxing when a >> vector value is alive across a safepoint. As with other values, >> there's just a location of the vector value at the safepoint and >> vector type information recorded in the relevant nmethod metadata and >> all the heavy-lifting happens only when rematerialization takes place. >> >> The analysis preserves object identity invariants except during >> aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). >> >> (Aggressive reboxing is crucial for cases when vectors "escape": it >> allocates a fresh instance at every escape point thus enabling >> original instance to go away.) >> >> =========================================================== >> >> (4) >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/03.module.hotspot/ >> >> >> HotSpot changes for jdk.incubator.vector module. Vector support is >> makred experimental and turned off by default. JEP 338 proposes the >> API to be released as an incubator module, so a user has to specify >> "--add-module jdk.incubator.vector" on the command line to be able to >> use it. >> When user does that, JVM automatically enables Vector API support. >> It improves usability (user doesn't need to separately "open" the API >> and enable JVM support) while minimizing risks of destabilitzation >> from new code when the API is not used. >> >> >> That's it! Will be happy to answer any questions. >> >> And thanks in advance for any feedback! >> >> Best regards, >> Vladimir Ivanov >> >> [0] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/0653 >> 4 >> 5.html >> >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228. >> html >> >> [2] https://openjdk.java.net/jeps/338 >> >> [3] https://openjdk.java.net/projects/panama/ >> >> [4] >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.sha >> r >> ed/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/v >> m >> /vector/VectorSupport.java.html >> >> >> [5] >> http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >> >> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >> >> ??? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b >> vector-unstable From serguei.spitsyn at oracle.com Wed Aug 5 02:22:20 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Aug 2020 19:22:20 -0700 Subject: RFR(L/S) : 8249030 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdi tests In-Reply-To: References: <637D6495-24E6-4874-9024-1B0082492085@oracle.com> Message-ID: Hi Igor, It looks okay to me. At least, I've not noticed any issues. Thanks, Serguei On 8/4/20 16:59, Igor Ignatyev wrote: > ping? > -- Igor > >> On Jul 31, 2020, at 1:24 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00 >>> 2258 lines changed: 0 ins; 1144 del; 1114 mod; >> Hi all, >> >> could you please review the clean-up of nsk_jdi tests? >> from main issue(8204985) : >>> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. >> >> the patch removes FileInstaller actions in the said tests, and as before, the biggest part of patch was done by `ag -l '@run driver jdk.test.lib.FileInstaller . .' $DIR | xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}` with $DIR being test/hotspot/jtreg/vmTestbase/nsk/jdi/. >> >> the 10 tests which had '-configFile ./<...>', and hence were looking for config file in the current directory, were updated to search for a config file in 'test.src' directory: http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00-configFile >> >> testing: :vmTestbase_nsk_jdi on {linux,windows,macos}-x64 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8249030 >> webrev: http://cr.openjdk.java.net/~iignatyev/8249030/webrev.00/ >> >> Thanks, >> -- Igor From david.holmes at oracle.com Wed Aug 5 02:26:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Aug 2020 12:26:24 +1000 Subject: RFR(L/S) : 8249030 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdi tests In-Reply-To: References: <637D6495-24E6-4874-9024-1B0082492085@oracle.com> Message-ID: That was a hard slog :) But looks okay to me. Thanks, David On 5/08/2020 9:59 am, Igor Ignatyev wrote: > ping? > -- Igor > >> On Jul 31, 2020, at 1:24 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00 >>> 2258 lines changed: 0 ins; 1144 del; 1114 mod; >> >> Hi all, >> >> could you please review the clean-up of nsk_jdi tests? >> from main issue(8204985) : >>> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. >> >> >> the patch removes FileInstaller actions in the said tests, and as before, the biggest part of patch was done by `ag -l '@run driver jdk.test.lib.FileInstaller . .' $DIR | xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}` with $DIR being test/hotspot/jtreg/vmTestbase/nsk/jdi/. >> >> the 10 tests which had '-configFile ./<...>', and hence were looking for config file in the current directory, were updated to search for a config file in 'test.src' directory: http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00-configFile >> >> testing: :vmTestbase_nsk_jdi on {linux,windows,macos}-x64 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8249030 >> webrev: http://cr.openjdk.java.net/~iignatyev/8249030/webrev.00/ >> >> Thanks, >> -- Igor > From david.holmes at oracle.com Wed Aug 5 02:29:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Aug 2020 12:29:26 +1000 Subject: RFR(S) : 8251126 : nsk.share.GoldChecker should read golden file from ${test.src} In-Reply-To: <7510EC68-7A8C-4F1E-A928-5910F13FA5D9@oracle.com> References: <7510EC68-7A8C-4F1E-A928-5910F13FA5D9@oracle.com> Message-ID: <41261a03-cd46-3d48-839b-d934a9fb92bb@oracle.com> Hi Igor, This seems fine. The code cleanup looks good too. Thanks, David On 5/08/2020 9:58 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ >> 37 lines changed: 7 ins; 20 del; 10 mod; > > Hi all, > > could you please review this patch? > from JBS: >> as of now, nsk.share.GoldChecker reads golden files from the current directory, which makes it necessary to copy golden files from ${test.src} before the execution of the tests which use GoldChecker. > > after this patch, FileInstaller actions will become redundant in 103 of :vmTestbase_vm_compiler tests and will be removed by 8251127. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8251126 > webrev: http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ > testing: :vmTestbase_vm_compiler tests > > 8251127: https://bugs.openjdk.java.net/browse/JDK-8251127 > > Thanks, > -- Igor > > From igor.ignatyev at oracle.com Wed Aug 5 03:08:45 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 4 Aug 2020 20:08:45 -0700 Subject: RFR(L/S) : 8249030 : clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdi tests In-Reply-To: References: <637D6495-24E6-4874-9024-1B0082492085@oracle.com> Message-ID: <9E8AE6ED-8DCD-473C-9AEB-9B0951F0180D@oracle.com> Serguei, David, thank you for your reviews. pushed. -- Igor > On Aug 4, 2020, at 7:26 PM, David Holmes wrote: > > That was a hard slog :) > > But looks okay to me. > > Thanks, > David > > On 5/08/2020 9:59 am, Igor Ignatyev wrote: >> ping? >> -- Igor >>> On Jul 31, 2020, at 1:24 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00 >>>> 2258 lines changed: 0 ins; 1144 del; 1114 mod; >>> >>> Hi all, >>> >>> could you please review the clean-up of nsk_jdi tests? >>> from main issue(8204985) : >>>> all vmTestbase tests have '@run driver jdk.test.lib.FileInstaller . .' to mimic old test harness behavior and copy all files from a test source directory to a current work directory. some tests depend on this step, so we need 1st identify such tests and then either rewrite them not to have this dependency or leave FileInstaller only in these tests. >>> >>> >>> the patch removes FileInstaller actions in the said tests, and as before, the biggest part of patch was done by `ag -l '@run driver jdk.test.lib.FileInstaller . .' $DIR | xargs -I{} gsed -i '/@run driver jdk.test.lib.FileInstaller \. \./d' {}` with $DIR being test/hotspot/jtreg/vmTestbase/nsk/jdi/. >>> >>> the 10 tests which had '-configFile ./<...>', and hence were looking for config file in the current directory, were updated to search for a config file in 'test.src' directory: http://cr.openjdk.java.net/~iignatyev//8249030/webrev.00-configFile >>> >>> testing: :vmTestbase_nsk_jdi on {linux,windows,macos}-x64 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249030 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8249030/webrev.00/ >>> >>> Thanks, >>> -- Igor From kim.barrett at oracle.com Wed Aug 5 06:40:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 5 Aug 2020 02:40:08 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <8058cd63-55d8-41bb-b776-c88b4e86831b@default> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> Message-ID: > On Aug 4, 2020, at 5:39 AM, Markus Gronlund wrote: > > About _last_sweep: > > The value, representing the last time the GC passed over the sample instances, is only treated as a hint, used as input to construct a filter when serializing object samples as events along with their associated chains. The filter excludes samples that are short-lived, i.e. having timestamps after the _last_sweep value. _last_sweep is only read by a single thread which at that moment have exclusive access to the sampler instance. It is ok for it to read whatever value leaked to it, in fact it can be advantageous to see an older value as it makes the filter more effective in reducing noise. Therefore, I think it is ok to leave an undecorated access to this variable. Also, there is no ordering constraint, the value is just reset when constructing a new instance, and a race is ok here too. In the old code, the write of _last_sweep was done during a weak_oops_do that was called by all GCs during a safepoint, thus providing the needed synchronization with the Java thread reads. In the new code, for a GC that does STW reference processing, the GC callback that updates _last_sweep is from that STW safepoint context, so still not concurrent with the sampling. However, for a GC that does concurrent reference processing, the GC callback is concurrent with mutator threads, so potentially concurrent with sampling. So we have unsynchronized non-atomic read/write pairs, which is UB. And that's UB being introduced by this change. And it's not one of those "undetectable" UB's that we sometimes squint and pretend isn't happening and hope the compiler never becomes smart enough to find. The value involved is a 64bit timestamp. If run on a 32bit platform, word tearing could ensue for the reader. A mitigating factor is that ZGC doesn't run on 32bit platforms and changing that is not on the roadmap. I don't know if Shenandoah has concurrent reference processing (yet), but it does support 32bit platforms: https://wiki.openjdk.java.net/display/shenandoah/Main Looking at the use of _last_sweep, it's not clear that it really needs to be a clock value; maybe it could just be a (atomic) counter? But that doesn't look like a simple change to make. From markus.gronlund at oracle.com Wed Aug 5 10:37:04 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 5 Aug 2020 03:37:04 -0700 (PDT) Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> Message-ID: <192aaa42-fa30-4a46-9715-b3c30e212d2e@default> Hi Kim, That is a good argument, thank you. So we would need Atomic accesses to the variable _last_sweep to prevent word tearing on 32-bit platforms for GCs that perform concurrent reference processing. About it currently being a clock value, and could instead be an natural number, that's a good observation too. We have thought about that change but never followed through with it, mainly because the stamping mechanism is not optimal from the start and we would like instead to come up with a better solution. Thanks Markus -----Original Message----- From: Kim Barrett Sent: den 5 augusti 2020 08:40 To: Markus Gronlund Cc: David Holmes ; Coleen Phillimore ; hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage > On Aug 4, 2020, at 5:39 AM, Markus Gronlund wrote: > > About _last_sweep: > > The value, representing the last time the GC passed over the sample instances, is only treated as a hint, used as input to construct a filter when serializing object samples as events along with their associated chains. The filter excludes samples that are short-lived, i.e. having timestamps after the _last_sweep value. _last_sweep is only read by a single thread which at that moment have exclusive access to the sampler instance. It is ok for it to read whatever value leaked to it, in fact it can be advantageous to see an older value as it makes the filter more effective in reducing noise. Therefore, I think it is ok to leave an undecorated access to this variable. Also, there is no ordering constraint, the value is just reset when constructing a new instance, and a race is ok here too. In the old code, the write of _last_sweep was done during a weak_oops_do that was called by all GCs during a safepoint, thus providing the needed synchronization with the Java thread reads. In the new code, for a GC that does STW reference processing, the GC callback that updates _last_sweep is from that STW safepoint context, so still not concurrent with the sampling. However, for a GC that does concurrent reference processing, the GC callback is concurrent with mutator threads, so potentially concurrent with sampling. So we have unsynchronized non-atomic read/write pairs, which is UB. And that's UB being introduced by this change. And it's not one of those "undetectable" UB's that we sometimes squint and pretend isn't happening and hope the compiler never becomes smart enough to find. The value involved is a 64bit timestamp. If run on a 32bit platform, word tearing could ensue for the reader. A mitigating factor is that ZGC doesn't run on 32bit platforms and changing that is not on the roadmap. I don't know if Shenandoah has concurrent reference processing (yet), but it does support 32bit platforms: https://wiki.openjdk.java.net/display/shenandoah/Main Looking at the use of _last_sweep, it's not clear that it really needs to be a clock value; maybe it could just be a (atomic) counter? But that doesn't look like a simple change to make. From coleen.phillimore at oracle.com Wed Aug 5 12:54:01 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 5 Aug 2020 08:54:01 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <192aaa42-fa30-4a46-9715-b3c30e212d2e@default> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> <192aaa42-fa30-4a46-9715-b3c30e212d2e@default> Message-ID: <2d8416f0-ad18-a245-1e32-4754fc177152@oracle.com> Kim, Thank you for the analysis why _last_sweep is a problem.? I am not happy to check in something with UB but I'd like to not try to fix a different problem with this patch.? Since there are currently no 32 bit GCs that do concurrent weak reference processing, I've filed another bug to have this fixed: https://bugs.openjdk.java.net/browse/JDK-8251179 Thanks for the in-depth review. Coleen On 8/5/20 6:37 AM, Markus Gronlund wrote: > Hi Kim, > > That is a good argument, thank you. > > So we would need Atomic accesses to the variable _last_sweep to prevent word tearing on 32-bit platforms for GCs that perform concurrent reference processing. > > About it currently being a clock value, and could instead be an natural number, that's a good observation too. We have thought about that change but never followed through with it, mainly because the stamping mechanism is not optimal from the start and we would like instead to come up with a better solution. > > Thanks > Markus > > -----Original Message----- > From: Kim Barrett > Sent: den 5 augusti 2020 08:40 > To: Markus Gronlund > Cc: David Holmes ; Coleen Phillimore ; hotspot-dev developers ; hotspot-jfr-dev at openjdk.java.net > Subject: Re: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage > >> On Aug 4, 2020, at 5:39 AM, Markus Gronlund wrote: >> >> About _last_sweep: >> >> The value, representing the last time the GC passed over the sample instances, is only treated as a hint, used as input to construct a filter when serializing object samples as events along with their associated chains. The filter excludes samples that are short-lived, i.e. having timestamps after the _last_sweep value. _last_sweep is only read by a single thread which at that moment have exclusive access to the sampler instance. It is ok for it to read whatever value leaked to it, in fact it can be advantageous to see an older value as it makes the filter more effective in reducing noise. Therefore, I think it is ok to leave an undecorated access to this variable. Also, there is no ordering constraint, the value is just reset when constructing a new instance, and a race is ok here too. > In the old code, the write of _last_sweep was done during a weak_oops_do that was called by all GCs during a safepoint, thus providing the needed synchronization with the Java thread reads. > > In the new code, for a GC that does STW reference processing, the GC callback that updates _last_sweep is from that STW safepoint context, so still not concurrent with the sampling. > > However, for a GC that does concurrent reference processing, the GC callback is concurrent with mutator threads, so potentially concurrent with sampling. > So we have unsynchronized non-atomic read/write pairs, which is UB. And that's UB being introduced by this change. > > And it's not one of those "undetectable" UB's that we sometimes squint and pretend isn't happening and hope the compiler never becomes smart enough to find. The value involved is a 64bit timestamp. If run on a 32bit platform, word tearing could ensue for the reader. > > A mitigating factor is that ZGC doesn't run on 32bit platforms and changing that is not on the roadmap. > > I don't know if Shenandoah has concurrent reference processing (yet), but it does support 32bit platforms: > https://wiki.openjdk.java.net/display/shenandoah/Main > > Looking at the use of _last_sweep, it's not clear that it really needs to be a clock value; maybe it could just be a (atomic) counter? But that doesn't look like a simple change to make. > From vladimir.x.ivanov at oracle.com Wed Aug 5 19:16:30 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Aug 2020 22:16:30 +0300 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: Thanks for the review, Vladimir. > compile.cpp: what is next comment about? > > +? // FIXME for_igvn() is corrupted from here: new_worklist which is > set_for_ignv() was allocated on stack. It documents a bug in the preceding code which makes for_igvn() node list unusable beyond that point: 2098 if (!failing() && RenumberLiveNodes && live_nodes() + NodeLimitFudgeFactor < unique()) { 2099 Compile::TracePhase tp("", &timers[_t_renumberLive]); 2100 initial_gvn()->replace_with(&igvn); 2101 for_igvn()->clear(); 2102 Unique_Node_List new_worklist(C->comp_arena()); 2103 { 2104 ResourceMark rm; 2105 PhaseRenumberLive prl = PhaseRenumberLive(initial_gvn(), for_igvn(), &new_worklist); 2106 } 2107 set_for_igvn(&new_worklist); 2108 igvn = PhaseIterGVN(initial_gvn()); 2109 igvn.optimize(); 2110 } 2111 2112 // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack. I'm fine with removing the commend and filing a bug instead. > print_method(): NodeClassNames[] should be available in product. > Node::Name() method is not, but we can move it to product. But I am fine > to do that later. Good point. I'll migrate print_method() to NodeClassNames[] for now. > Why VectorSupport.java does not have copyright header? Good catch! Will fix it and incorporate into the webrev in-place shortly. Best regards, Vladimir Ivanov > On 7/28/20 3:29 PM, Vladimir Ivanov wrote: >> Hi, >> >> Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and >> Ekaterina! >> >> Here are the latest changes for Vector API support in HotSpot shared >> code: >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 >> >> >> Incremental changes (diff against webrev.00): >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 >> >> >> I decided to post it here and not initiate a new round of reviews >> because the changes are mostly limited to minor cleanups / simple bug >> fixes. >> >> Detailed summary: >> ?? - rebased to jdk/jdk tip; >> ?? - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; >> ?? - restore lazy cleanup logic during incremental inlining (see >> needs_cleanup in compile.cpp); >> ?? - got rid of x86-specific changes in shared code; >> ?? - fix for 8244867 [1]; >> ?? - fix Graal test failure: enumerate VectorSupport intrinsics in >> CheckGraalIntrinsics >> ?? - numerous minor cleanups >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 >> ???? http://jbs.oracle.com/browse/JDK-8244867 >> ???? 8244867: 2 vector api tests crash with >> assert(is_reference_type(basic_type())) failed: wrong type >> Summary: Adding safety checks to prevent intrinsification if class >> arguments of non-primitive types are uninitialized. >> >> On 04.04.2020 02:12, Vladimir Ivanov wrote: >>> Hi, >>> >>> Following up on review requests of API [0] and Java implementation >>> [1] for Vector API (JEP 338 [2]), here's a request for review of >>> general HotSpot changes (in shared code) required for supporting the >>> API: >>> >>> >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ >>> >>> >>> (First of all, to set proper expectations: since the JEP is still in >>> Candidate state, the intention is to initiate preliminary round(s) of >>> review to inform the community and gather feedback before sending out >>> final/official RFRs once the JEP is Targeted to a release.) >>> >>> Vector API (being developed in Project Panama [3]) relies on JVM >>> support to utilize optimal vector hardware instructions at runtime. >>> It interacts with JVM through intrinsics (declared in >>> jdk.internal.vm.vector.VectorSupport [4]) which expose vector >>> operations support in C2 JIT-compiler. >>> >>> As Paul wrote earlier: "A vector intrinsic is an internal low-level >>> vector operation. The last argument to the intrinsic is fall back >>> behavior in Java, implementing the scalar operation over the number >>> of elements held by the vector.? Thus, If the intrinsic is not >>> supported in C2 for the other arguments then the Java implementation >>> is executed (the Java implementation is always executed when running >>> in the interpreter or for C1)." >>> >>> The rest of JVM support is about aggressively optimizing vector boxes >>> to minimize (ideally eliminate) the overhead of boxing for vector >>> values. >>> It's a stop-the-gap solution for vector box elimination problem until >>> inline classes arrive. Vector classes are value-based and in the >>> longer term will be migrated to inline classes once the support >>> becomes available. >>> >>> Vector API talk from JVMLS'18 [5] contains brief overview of JVM >>> implementation and some details. >>> >>> Complete implementation resides in vector-unstable branch of >>> panama/dev repository [6]. >>> >>> Now to gory details (the patch is split in multiple "sub-webrevs"): >>> >>> =========================================================== >>> >>> (1) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ >>> >>> >>> Ideal vector nodes for new operations introduced by Vector API. >>> >>> (Platform-specific back end support will be posted for review >>> separately). >>> >>> =========================================================== >>> >>> (2) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ >>> >>> >>> JVM Java interface (VectorSupport) and intrinsic support in C2. >>> >>> Vector instances are initially represented as VectorBox macro nodes >>> and "unboxing" is represented by VectorUnbox node. It simplifies >>> vector box elimination analysis and the nodes are expanded later >>> right before EA pass. >>> >>> Vectors have 2-level on-heap representation: for the vector value >>> primitive array is used as a backing storage and it is encapsulated >>> in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains >>> a int[8] instance which is used to store vector value). >>> >>> Unless VectorBox node goes away, it needs to be expanded into an >>> allocation eventually, but it is a pure node and doesn't have any JVM >>> state associated with it. The problem is solved by keeping JVM state >>> separately in a VectorBoxAllocate node associated with VectorBox node >>> and use it during expansion. >>> >>> Also, to simplify vector box elimination, inlining of vector reboxing >>> calls (VectorSupport::maybeRebox) is delayed until the analysis is over. >>> >>> =========================================================== >>> >>> (3) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ >>> >>> >>> Vector box elimination analysis implementation. (Brief overview: >>> slides #36-42 [5].) >>> >>> The main part is devoted to scalarization across safepoints and >>> rematerialization support during deoptimization. In C2-generated code >>> vector operations work with raw vector values which live in registers >>> or spilled on the stack and it allows to avoid boxing/unboxing when a >>> vector value is alive across a safepoint. As with other values, >>> there's just a location of the vector value at the safepoint and >>> vector type information recorded in the relevant nmethod metadata and >>> all the heavy-lifting happens only when rematerialization takes place. >>> >>> The analysis preserves object identity invariants except during >>> aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). >>> >>> (Aggressive reboxing is crucial for cases when vectors "escape": it >>> allocates a fresh instance at every escape point thus enabling >>> original instance to go away.) >>> >>> =========================================================== >>> >>> (4) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ >>> >>> >>> HotSpot changes for jdk.incubator.vector module. Vector support is >>> makred experimental and turned off by default. JEP 338 proposes the >>> API to be released as an incubator module, so a user has to specify >>> "--add-module jdk.incubator.vector" on the command line to be able to >>> use it. >>> When user does that, JVM automatically enables Vector API support. >>> It improves usability (user doesn't need to separately "open" the API >>> and enable JVM support) while minimizing risks of destabilitzation >>> from new code when the API is not used. >>> >>> >>> That's it! Will be happy to answer any questions. >>> >>> And thanks in advance for any feedback! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [0] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html >>> >>> >>> [2] https://openjdk.java.net/jeps/338 >>> >>> [3] https://openjdk.java.net/projects/panama/ >>> >>> [4] >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html >>> >>> >>> [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >>> >>> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >>> >>> ???? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b >>> vector-unstable From vladimir.x.ivanov at oracle.com Wed Aug 5 19:17:00 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 5 Aug 2020 22:17:00 +0300 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: <9c538834-903b-5431-bb43-908b58a1b70a@oracle.com> References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> <9c538834-903b-5431-bb43-908b58a1b70a@oracle.com> Message-ID: <90f71dc2-8ff0-5956-d08d-0af28f59c7df@oracle.com> Thanks for the review, Coleen. Best regards, Vladimir Ivanov On 31.07.2020 22:38, coleen.phillimore at oracle.com wrote: > The runtime code still looks good to me. > Coleen > > On 7/28/20 6:29 PM, Vladimir Ivanov wrote: >> Hi, >> >> Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and >> Ekaterina! >> >> Here are the latest changes for Vector API support in HotSpot shared >> code: >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 >> >> >> Incremental changes (diff against webrev.00): >> >> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 >> >> >> I decided to post it here and not initiate a new round of reviews >> because the changes are mostly limited to minor cleanups / simple bug >> fixes. >> >> Detailed summary: >> ? - rebased to jdk/jdk tip; >> ? - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; >> ? - restore lazy cleanup logic during incremental inlining (see >> needs_cleanup in compile.cpp); >> ? - got rid of x86-specific changes in shared code; >> ? - fix for 8244867 [1]; >> ? - fix Graal test failure: enumerate VectorSupport intrinsics in >> CheckGraalIntrinsics >> ? - numerous minor cleanups >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 >> ??? http://jbs.oracle.com/browse/JDK-8244867 >> ??? 8244867: 2 vector api tests crash with >> assert(is_reference_type(basic_type())) failed: wrong type >> Summary: Adding safety checks to prevent intrinsification if class >> arguments of non-primitive types are uninitialized. >> >> On 04.04.2020 02:12, Vladimir Ivanov wrote: >>> Hi, >>> >>> Following up on review requests of API [0] and Java implementation >>> [1] for Vector API (JEP 338 [2]), here's a request for review of >>> general HotSpot changes (in shared code) required for supporting the >>> API: >>> >>> >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ >>> >>> >>> (First of all, to set proper expectations: since the JEP is still in >>> Candidate state, the intention is to initiate preliminary round(s) of >>> review to inform the community and gather feedback before sending out >>> final/official RFRs once the JEP is Targeted to a release.) >>> >>> Vector API (being developed in Project Panama [3]) relies on JVM >>> support to utilize optimal vector hardware instructions at runtime. >>> It interacts with JVM through intrinsics (declared in >>> jdk.internal.vm.vector.VectorSupport [4]) which expose vector >>> operations support in C2 JIT-compiler. >>> >>> As Paul wrote earlier: "A vector intrinsic is an internal low-level >>> vector operation. The last argument to the intrinsic is fall back >>> behavior in Java, implementing the scalar operation over the number >>> of elements held by the vector.? Thus, If the intrinsic is not >>> supported in C2 for the other arguments then the Java implementation >>> is executed (the Java implementation is always executed when running >>> in the interpreter or for C1)." >>> >>> The rest of JVM support is about aggressively optimizing vector boxes >>> to minimize (ideally eliminate) the overhead of boxing for vector >>> values. >>> It's a stop-the-gap solution for vector box elimination problem until >>> inline classes arrive. Vector classes are value-based and in the >>> longer term will be migrated to inline classes once the support >>> becomes available. >>> >>> Vector API talk from JVMLS'18 [5] contains brief overview of JVM >>> implementation and some details. >>> >>> Complete implementation resides in vector-unstable branch of >>> panama/dev repository [6]. >>> >>> Now to gory details (the patch is split in multiple "sub-webrevs"): >>> >>> =========================================================== >>> >>> (1) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ >>> >>> >>> Ideal vector nodes for new operations introduced by Vector API. >>> >>> (Platform-specific back end support will be posted for review >>> separately). >>> >>> =========================================================== >>> >>> (2) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ >>> >>> >>> JVM Java interface (VectorSupport) and intrinsic support in C2. >>> >>> Vector instances are initially represented as VectorBox macro nodes >>> and "unboxing" is represented by VectorUnbox node. It simplifies >>> vector box elimination analysis and the nodes are expanded later >>> right before EA pass. >>> >>> Vectors have 2-level on-heap representation: for the vector value >>> primitive array is used as a backing storage and it is encapsulated >>> in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains >>> a int[8] instance which is used to store vector value). >>> >>> Unless VectorBox node goes away, it needs to be expanded into an >>> allocation eventually, but it is a pure node and doesn't have any JVM >>> state associated with it. The problem is solved by keeping JVM state >>> separately in a VectorBoxAllocate node associated with VectorBox node >>> and use it during expansion. >>> >>> Also, to simplify vector box elimination, inlining of vector reboxing >>> calls (VectorSupport::maybeRebox) is delayed until the analysis is over. >>> >>> =========================================================== >>> >>> (3) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ >>> >>> >>> Vector box elimination analysis implementation. (Brief overview: >>> slides #36-42 [5].) >>> >>> The main part is devoted to scalarization across safepoints and >>> rematerialization support during deoptimization. In C2-generated code >>> vector operations work with raw vector values which live in registers >>> or spilled on the stack and it allows to avoid boxing/unboxing when a >>> vector value is alive across a safepoint. As with other values, >>> there's just a location of the vector value at the safepoint and >>> vector type information recorded in the relevant nmethod metadata and >>> all the heavy-lifting happens only when rematerialization takes place. >>> >>> The analysis preserves object identity invariants except during >>> aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing). >>> >>> (Aggressive reboxing is crucial for cases when vectors "escape": it >>> allocates a fresh instance at every escape point thus enabling >>> original instance to go away.) >>> >>> =========================================================== >>> >>> (4) >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ >>> >>> >>> HotSpot changes for jdk.incubator.vector module. Vector support is >>> makred experimental and turned off by default. JEP 338 proposes the >>> API to be released as an incubator module, so a user has to specify >>> "--add-module jdk.incubator.vector" on the command line to be able to >>> use it. >>> When user does that, JVM automatically enables Vector API support. >>> It improves usability (user doesn't need to separately "open" the API >>> and enable JVM support) while minimizing risks of destabilitzation >>> from new code when the API is not used. >>> >>> >>> That's it! Will be happy to answer any questions. >>> >>> And thanks in advance for any feedback! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [0] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html >>> >>> >>> [2] https://openjdk.java.net/jeps/338 >>> >>> [3] https://openjdk.java.net/projects/panama/ >>> >>> [4] >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html >>> >>> >>> [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >>> >>> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >>> >>> ???? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b >>> vector-unstable > From vladimir.kozlov at oracle.com Wed Aug 5 19:18:39 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Aug 2020 12:18:39 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes In-Reply-To: References: <38a7fe74-0c5e-4a28-b128-24c40b8ea01e@oracle.com> Message-ID: <6f25a6c6-c675-ee46-596d-f97a4119b95a@oracle.com> On 8/5/20 12:16 PM, Vladimir Ivanov wrote: > Thanks for the review, Vladimir. > >> compile.cpp: what is next comment about? >> >> +? // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack. > > It documents a bug in the preceding code which makes for_igvn() node list unusable beyond that point: > > 2098?? if (!failing() && RenumberLiveNodes && live_nodes() + NodeLimitFudgeFactor < unique()) { > 2099???? Compile::TracePhase tp("", &timers[_t_renumberLive]); > 2100???? initial_gvn()->replace_with(&igvn); > 2101???? for_igvn()->clear(); > 2102???? Unique_Node_List new_worklist(C->comp_arena()); > 2103???? { > 2104?????? ResourceMark rm; > 2105?????? PhaseRenumberLive prl = PhaseRenumberLive(initial_gvn(), for_igvn(), &new_worklist); > 2106???? } > 2107???? set_for_igvn(&new_worklist); > 2108???? igvn = PhaseIterGVN(initial_gvn()); > 2109???? igvn.optimize(); > 2110?? } > 2111 > 2112?? // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack. > > I'm fine with removing the commend and filing a bug instead. Yes, please. > >> print_method(): NodeClassNames[] should be available in product. Node::Name() method is not, but we can move it to >> product. But I am fine to do that later. > > Good point. I'll migrate print_method() to NodeClassNames[] for now. Okay. > >> Why VectorSupport.java does not have copyright header? > > Good catch! Will fix it and incorporate into the webrev in-place shortly. Thanks, Vladimir K > > Best regards, > Vladimir Ivanov > >> On 7/28/20 3:29 PM, Vladimir Ivanov wrote: >>> Hi, >>> >>> Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and Ekaterina! >>> >>> Here are the latest changes for Vector API support in HotSpot shared code: >>> >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 >>> >>> Incremental changes (diff against webrev.00): >>> >>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 >>> >>> I decided to post it here and not initiate a new round of reviews because the changes are mostly limited to minor >>> cleanups / simple bug fixes. >>> >>> Detailed summary: >>> ?? - rebased to jdk/jdk tip; >>> ?? - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes; >>> ?? - restore lazy cleanup logic during incremental inlining (see needs_cleanup in compile.cpp); >>> ?? - got rid of x86-specific changes in shared code; >>> ?? - fix for 8244867 [1]; >>> ?? - fix Graal test failure: enumerate VectorSupport intrinsics in CheckGraalIntrinsics >>> ?? - numerous minor cleanups >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977 >>> ???? http://jbs.oracle.com/browse/JDK-8244867 >>> ???? 8244867: 2 vector api tests crash with assert(is_reference_type(basic_type())) failed: wrong type >>> Summary: Adding safety checks to prevent intrinsification if class arguments of non-primitive types are uninitialized. >>> >>> On 04.04.2020 02:12, Vladimir Ivanov wrote: >>>> Hi, >>>> >>>> Following up on review requests of API [0] and Java implementation [1] for Vector API (JEP 338 [2]), here's a >>>> request for review of general HotSpot changes (in shared code) required for supporting the API: >>>> >>>> >>>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/ >>>> >>>> (First of all, to set proper expectations: since the JEP is still in Candidate state, the intention is to initiate >>>> preliminary round(s) of review to inform the community and gather feedback before sending out final/official RFRs >>>> once the JEP is Targeted to a release.) >>>> >>>> Vector API (being developed in Project Panama [3]) relies on JVM support to utilize optimal vector hardware >>>> instructions at runtime. It interacts with JVM through intrinsics (declared in jdk.internal.vm.vector.VectorSupport >>>> [4]) which expose vector operations support in C2 JIT-compiler. >>>> >>>> As Paul wrote earlier: "A vector intrinsic is an internal low-level vector operation. The last argument to the >>>> intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the >>>> vector.? Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is >>>> executed (the Java implementation is always executed when running in the interpreter or for C1)." >>>> >>>> The rest of JVM support is about aggressively optimizing vector boxes to minimize (ideally eliminate) the overhead >>>> of boxing for vector values. >>>> It's a stop-the-gap solution for vector box elimination problem until inline classes arrive. Vector classes are >>>> value-based and in the longer term will be migrated to inline classes once the support becomes available. >>>> >>>> Vector API talk from JVMLS'18 [5] contains brief overview of JVM implementation and some details. >>>> >>>> Complete implementation resides in vector-unstable branch of panama/dev repository [6]. >>>> >>>> Now to gory details (the patch is split in multiple "sub-webrevs"): >>>> >>>> =========================================================== >>>> >>>> (1) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/ >>>> >>>> Ideal vector nodes for new operations introduced by Vector API. >>>> >>>> (Platform-specific back end support will be posted for review separately). >>>> >>>> =========================================================== >>>> >>>> (2) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/ >>>> >>>> JVM Java interface (VectorSupport) and intrinsic support in C2. >>>> >>>> Vector instances are initially represented as VectorBox macro nodes and "unboxing" is represented by VectorUnbox >>>> node. It simplifies vector box elimination analysis and the nodes are expanded later right before EA pass. >>>> >>>> Vectors have 2-level on-heap representation: for the vector value primitive array is used as a backing storage and >>>> it is encapsulated in a typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a int[8] instance which is >>>> used to store vector value). >>>> >>>> Unless VectorBox node goes away, it needs to be expanded into an allocation eventually, but it is a pure node and >>>> doesn't have any JVM state associated with it. The problem is solved by keeping JVM state separately in a >>>> VectorBoxAllocate node associated with VectorBox node and use it during expansion. >>>> >>>> Also, to simplify vector box elimination, inlining of vector reboxing calls (VectorSupport::maybeRebox) is delayed >>>> until the analysis is over. >>>> >>>> =========================================================== >>>> >>>> (3) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/ >>>> >>>> Vector box elimination analysis implementation. (Brief overview: slides #36-42 [5].) >>>> >>>> The main part is devoted to scalarization across safepoints and rematerialization support during deoptimization. In >>>> C2-generated code vector operations work with raw vector values which live in registers or spilled on the stack and >>>> it allows to avoid boxing/unboxing when a vector value is alive across a safepoint. As with other values, there's >>>> just a location of the vector value at the safepoint and vector type information recorded in the relevant nmethod >>>> metadata and all the heavy-lifting happens only when rematerialization takes place. >>>> >>>> The analysis preserves object identity invariants except during aggressive reboxing (guarded by >>>> -XX:+EnableAggressiveReboxing). >>>> >>>> (Aggressive reboxing is crucial for cases when vectors "escape": it allocates a fresh instance at every escape point >>>> thus enabling original instance to go away.) >>>> >>>> =========================================================== >>>> >>>> (4) http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/ >>>> >>>> HotSpot changes for jdk.incubator.vector module. Vector support is makred experimental and turned off by default. >>>> JEP 338 proposes the API to be released as an incubator module, so a user has to specify "--add-module >>>> jdk.incubator.vector" on the command line to be able to use it. >>>> When user does that, JVM automatically enables Vector API support. >>>> It improves usability (user doesn't need to separately "open" the API and enable JVM support) while minimizing risks >>>> of destabilitzation from new code when the API is not used. >>>> >>>> >>>> That's it! Will be happy to answer any questions. >>>> >>>> And thanks in advance for any feedback! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html >>>> >>>> [2] https://openjdk.java.net/jeps/338 >>>> >>>> [3] https://openjdk.java.net/projects/panama/ >>>> >>>> [4] >>>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html >>>> >>>> >>>> [5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf >>>> >>>> [6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9 >>>> >>>> ???? $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From igor.ignatyev at oracle.com Wed Aug 5 23:54:26 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 5 Aug 2020 16:54:26 -0700 Subject: RFR(S) : 8251126 : nsk.share.GoldChecker should read golden file from ${test.src} In-Reply-To: <41261a03-cd46-3d48-839b-d934a9fb92bb@oracle.com> References: <7510EC68-7A8C-4F1E-A928-5910F13FA5D9@oracle.com> <41261a03-cd46-3d48-839b-d934a9fb92bb@oracle.com> Message-ID: <35C137CF-698C-4396-B68E-98A158CE481F@oracle.com> Hi David, thanks for your review, pushed. -- Igor > On Aug 4, 2020, at 7:29 PM, David Holmes wrote: > > Hi Igor, > > This seems fine. The code cleanup looks good too. > > Thanks, > David > > On 5/08/2020 9:58 am, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ >>> 37 lines changed: 7 ins; 20 del; 10 mod; >> Hi all, >> could you please review this patch? >> from JBS: >>> as of now, nsk.share.GoldChecker reads golden files from the current directory, which makes it necessary to copy golden files from ${test.src} before the execution of the tests which use GoldChecker. >> after this patch, FileInstaller actions will become redundant in 103 of :vmTestbase_vm_compiler tests and will be removed by 8251127. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8251126 >> webrev: http://cr.openjdk.java.net/~iignatyev/8251126/webrev.00/ >> testing: :vmTestbase_vm_compiler tests >> 8251127: https://bugs.openjdk.java.net/browse/JDK-8251127 >> Thanks, >> -- Igor From kim.barrett at oracle.com Thu Aug 6 01:47:13 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 5 Aug 2020 21:47:13 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <2d8416f0-ad18-a245-1e32-4754fc177152@oracle.com> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> <192aaa42-fa30-4a46-9715-b3c30e212d2e@default> <2d8416f0-ad18-a245-1e32-4754fc177152@oracle.com> Message-ID: <177EE0DE-FDCA-460E-AEA9-EB899A30EE97@oracle.com> > On Aug 5, 2020, at 8:54 AM, Coleen Phillimore wrote: > Thank you for the analysis why _last_sweep is a problem. I am not happy to check in something with UB but I'd like to not try to fix a different problem with this patch. Understood. > Since there are currently no 32 bit GCs that do concurrent weak reference processing, I've filed another bug to have this fixed: https://bugs.openjdk.java.net/browse/JDK-8251179 OK. I think Markus plans to deal with that quickly, once your change is in. So your change looks good to me. From coleen.phillimore at oracle.com Thu Aug 6 12:00:20 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 08:00:20 -0400 Subject: RFR (M) 8235573: Move JFR ObjectSample oop into OopStorage In-Reply-To: <177EE0DE-FDCA-460E-AEA9-EB899A30EE97@oracle.com> References: <1fbb13cc-efd1-d473-bedf-5415dcf8b227@oracle.com> <41a84464-cc3a-9968-3ae8-d6f49361aae9@oracle.com> <8058cd63-55d8-41bb-b776-c88b4e86831b@default> <192aaa42-fa30-4a46-9715-b3c30e212d2e@default> <2d8416f0-ad18-a245-1e32-4754fc177152@oracle.com> <177EE0DE-FDCA-460E-AEA9-EB899A30EE97@oracle.com> Message-ID: <338eaac8-7fe5-8309-10e0-1c4fe65d160a@oracle.com> On 8/5/20 9:47 PM, Kim Barrett wrote: >> On Aug 5, 2020, at 8:54 AM, Coleen Phillimore wrote: >> Thank you for the analysis why _last_sweep is a problem. I am not happy to check in something with UB but I'd like to not try to fix a different problem with this patch. > Understood. > >> Since there are currently no 32 bit GCs that do concurrent weak reference processing, I've filed another bug to have this fixed: https://bugs.openjdk.java.net/browse/JDK-8251179 > OK. I think Markus plans to deal with that quickly, once your change is in. > > So your change looks good to me. Thank you, Kim. Coleen > From coleen.phillimore at oracle.com Thu Aug 6 12:40:43 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 08:40:43 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage Message-ID: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Summary: Move the oop and handle releasing it in the service thread.? Remove Universe::oops_do from callers. See bug for more details and discussion.? C2 code provided by Erik Osterlund and Graal changes provided by Tom Rodriguez. Tested with tiers 1-8. bug link https://bugs.openjdk.java.net/browse/JDK-8244997 open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev Copyrights fixed, not in this webrev. Thanks, Coleen From david.holmes at oracle.com Thu Aug 6 13:17:50 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Aug 2020 23:17:50 +1000 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: <581bad38-b724-5632-d618-c966c827e4d0@oracle.com> Hi Coleen, Thanks for all the work behind the scenes on checking the performance impacts of this (which for the record seem to be zero :)). Can't comment on the details of the JIT changes but otherwise this all looks good to me. One typo below. On 6/08/2020 10:40 pm, Coleen Phillimore wrote: > Summary: Move the oop and handle releasing it in the service thread. > Remove Universe::oops_do from callers. > > See bug for more details and discussion.? C2 code provided by Erik > Osterlund and Graal changes provided by Tom Rodriguez. > > Tested with tiers 1-8. > > bug link https://bugs.openjdk.java.net/browse/JDK-8244997 > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java // This substitution is no longer in used when threadObj is a handle typo: s/used/use/ or s/in used/used/ Thanks, David ----- > Copyrights fixed, not in this webrev. > > Thanks, > Coleen From zgu at redhat.com Thu Aug 6 13:44:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Aug 2020 09:44:56 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: <5b83b2c2-646c-ee3e-cfbf-2d311c523b5b@redhat.com> Hi Coleen, Shenandoah part looks good to me. Thanks, -Zhengyu On 8/6/20 8:40 AM, Coleen Phillimore wrote: > Summary: Move the oop and handle releasing it in the service thread. > Remove Universe::oops_do from callers. > > See bug for more details and discussion.? C2 code provided by Erik > Osterlund and Graal changes provided by Tom Rodriguez. > > Tested with tiers 1-8. > > bug link https://bugs.openjdk.java.net/browse/JDK-8244997 > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev > > Copyrights fixed, not in this webrev. > > Thanks, > Coleen > From erik.osterlund at oracle.com Thu Aug 6 13:45:06 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 6 Aug 2020 15:45:06 +0200 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: Hi Coleen, I think this looks good. One nit. In the C1 code, the first load should be T_ADDRESS instead of T_METADATA. Don't need another webrev for that. Thanks, /Erik On 2020-08-06 14:40, Coleen Phillimore wrote: > Summary: Move the oop and handle releasing it in the service thread. > Remove Universe::oops_do from callers. > > See bug for more details and discussion.? C2 code provided by Erik > Osterlund and Graal changes provided by Tom Rodriguez. > > Tested with tiers 1-8. > > bug link https://bugs.openjdk.java.net/browse/JDK-8244997 > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev > > Copyrights fixed, not in this webrev. > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Aug 6 14:38:25 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 10:38:25 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <581bad38-b724-5632-d618-c966c827e4d0@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> <581bad38-b724-5632-d618-c966c827e4d0@oracle.com> Message-ID: On 8/6/20 9:17 AM, David Holmes wrote: > Hi Coleen, > > Thanks for all the work behind the scenes on checking the performance > impacts of this (which for the record seem to be zero :)). > > Can't comment on the details of the JIT changes but otherwise this all > looks good to me. One typo below. > > On 6/08/2020 10:40 pm, Coleen Phillimore wrote: >> Summary: Move the oop and handle releasing it in the service thread. >> Remove Universe::oops_do from callers. >> >> See bug for more details and discussion.? C2 code provided by Erik >> Osterlund and Graal changes provided by Tom Rodriguez. >> >> Tested with tiers 1-8. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java > > > ?// This substitution is no longer in used when threadObj is a handle > > typo: s/used/use/? or s/in used/used/ Thanks for reviewing the code and reviewing the performance testing results. I fixed this typo. Coleen > > Thanks, > David > ----- > >> Copyrights fixed, not in this webrev. >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Aug 6 14:38:43 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 10:38:43 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <5b83b2c2-646c-ee3e-cfbf-2d311c523b5b@redhat.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> <5b83b2c2-646c-ee3e-cfbf-2d311c523b5b@redhat.com> Message-ID: On 8/6/20 9:44 AM, Zhengyu Gu wrote: > Hi Coleen, > > Shenandoah part looks good to me. Thanks Zhengyu! Coleen > > Thanks, > > -Zhengyu > > On 8/6/20 8:40 AM, Coleen Phillimore wrote: >> Summary: Move the oop and handle releasing it in the service thread. >> Remove Universe::oops_do from callers. >> >> See bug for more details and discussion.? C2 code provided by Erik >> Osterlund and Graal changes provided by Tom Rodriguez. >> >> Tested with tiers 1-8. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >> >> Copyrights fixed, not in this webrev. >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Thu Aug 6 14:39:05 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 10:39:05 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: <46595fbb-4cd1-7c86-6145-8b8ee5533627@oracle.com> On 8/6/20 9:45 AM, Erik ?sterlund wrote: > Hi Coleen, > > I think this looks good. > > One nit. In the C1 code, the first load should be T_ADDRESS instead of > T_METADATA. > Don't need another webrev for that. Thanks Erik.? I'll fix that. Coleen > > Thanks, > /Erik > > On 2020-08-06 14:40, Coleen Phillimore wrote: >> Summary: Move the oop and handle releasing it in the service thread. >> Remove Universe::oops_do from callers. >> >> See bug for more details and discussion.? C2 code provided by Erik >> Osterlund and Graal changes provided by Tom Rodriguez. >> >> Tested with tiers 1-8. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >> >> Copyrights fixed, not in this webrev. >> >> Thanks, >> Coleen > From beurba at microsoft.com Thu Aug 6 15:13:42 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 6 Aug 2020 15:13:42 +0000 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: , , Message-ID: Hello, can someone sponsor this change please? Webrev: http://cr.openjdk.java.net/~burban/8248816/ Thank you, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Friday, July 31, 2020 11:26 To: Andrew Haley; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply Thank you for the review Andrew. I've updated the Reviewed-By line in the Webrev: http://cr.openjdk.java.net/~burban/8248816/ -Bernhard ________________________________________ From: Andrew Haley Sent: Thursday, July 30, 2020 19:14 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply On 30/07/2020 14:11, Bernhard Urban-Forster wrote: > Hi all, > > this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248816&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=28A9Rb7tzDC0rGgUJM6hQglZxzRmKBPtqEnXEbWYxWM%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248816%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=trUG1lHI%2F4CONPNFZQfZAai336f6vGfmsvbX5QTMLMs%3D&reserved=0 OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=NYh2gNU6IIcZa4NW8eP173%2FoXpstoVF%2B02dFZsYTFzY%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From chris.plummer at oracle.com Thu Aug 6 16:20:28 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 6 Aug 2020 09:20:28 -0700 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: Hi Coleen, SA changes look good. thanks, Chris On 8/6/20 5:40 AM, Coleen Phillimore wrote: > Summary: Move the oop and handle releasing it in the service thread. > Remove Universe::oops_do from callers. > > See bug for more details and discussion.? C2 code provided by Erik > Osterlund and Graal changes provided by Tom Rodriguez. > > Tested with tiers 1-8. > > bug link https://bugs.openjdk.java.net/browse/JDK-8244997 > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev > > Copyrights fixed, not in this webrev. > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Aug 6 16:21:12 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 12:21:12 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> Message-ID: Thanks Chris! Coleen On 8/6/20 12:20 PM, Chris Plummer wrote: > Hi Coleen, > > SA changes look good. > > thanks, > > Chris > > On 8/6/20 5:40 AM, Coleen Phillimore wrote: >> Summary: Move the oop and handle releasing it in the service thread. >> Remove Universe::oops_do from callers. >> >> See bug for more details and discussion.? C2 code provided by Erik >> Osterlund and Graal changes provided by Tom Rodriguez. >> >> Tested with tiers 1-8. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >> >> Copyrights fixed, not in this webrev. >> >> Thanks, >> Coleen > > From coleen.phillimore at oracle.com Thu Aug 6 18:38:31 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 14:38:31 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <46595fbb-4cd1-7c86-6145-8b8ee5533627@oracle.com> References: <8adaee9d-eb15-93c8-9fa3-f163b475ce9f@oracle.com> <46595fbb-4cd1-7c86-6145-8b8ee5533627@oracle.com> Message-ID: <34a579bb-281e-3c27-7526-eead98555421@oracle.com> On 8/6/20 10:39 AM, Coleen Phillimore wrote: > > > On 8/6/20 9:45 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >> I think this looks good. >> >> One nit. In the C1 code, the first load should be T_ADDRESS instead >> of T_METADATA. >> Don't need another webrev for that. > > Thanks Erik.? I'll fix that. Unfortunately, this change ran into an assert that I had to make accept T_ADDRESS.? After that c1 works fine. http://cr.openjdk.java.net/~coleenp/2020/8244997.02.incr/webrev/index.html Reran tier1 tests on Oracle platforms, and cross compiled on linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. Thanks, Coleen > Coleen > >> >> Thanks, >> /Erik >> >> On 2020-08-06 14:40, Coleen Phillimore wrote: >>> Summary: Move the oop and handle releasing it in the service thread. >>> Remove Universe::oops_do from callers. >>> >>> See bug for more details and discussion.? C2 code provided by Erik >>> Osterlund and Graal changes provided by Tom Rodriguez. >>> >>> Tested with tiers 1-8. >>> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >>> >>> Copyrights fixed, not in this webrev. >>> >>> Thanks, >>> Coleen >> > From Divino.Cesar at microsoft.com Thu Aug 6 21:30:58 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Thu, 6 Aug 2020 21:30:58 +0000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8244801 Webrev: https://cr.openjdk.java.net/~adityam/cesar/8244801/0/ Need sponsor: Yes Can you please review the above linked patch for the mentioned bug? It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. I tried to structure the code so that the new code and the old printed the same log messages. Please let me know if you want to simplify the method signature and just hard code the log message. I also tried to come up with a short yet descriptive name for the method; let me know if you have suggestions on that as well. Thanks, Cesar Software Engineer - Microsoft From markus.gronlund at oracle.com Thu Aug 6 22:09:13 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 6 Aug 2020 15:09:13 -0700 (PDT) Subject: RFR(XS): 8251179: Word tearing problem with _last_sweep Message-ID: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> Greetings, This is a follow-up to 8235573: Move JFR ObjectSample oop into OopStorage. As of JDK-8235573, the static variable _last_sweep in objectSampler.cpp can be modified and read concurrently. For 64 bit platforms, this isn't a problem but for 32 bit platforms that support concurrent weak reference processing, this could word tear. This change adds atomic accesses for said variable. Bug: https://bugs.openjdk.java.net/browse/JDK-8251179 Webrev: http://cr.openjdk.java.net/~mgronlun/8251179/webrev00/ Testing: jdk_jfr Thank you Markus From coleen.phillimore at oracle.com Thu Aug 6 22:20:18 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 6 Aug 2020 18:20:18 -0400 Subject: RFR(XS): 8251179: Word tearing problem with _last_sweep In-Reply-To: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> References: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> Message-ID: <758d5dfb-1f08-233c-1d21-4c465eaf1cd0@oracle.com> This looks good to me.? Thank you for fixing this! Coleen On 8/6/20 6:09 PM, Markus Gronlund wrote: > Greetings, > > This is a follow-up to 8235573: Move JFR ObjectSample oop into OopStorage. > > As of JDK-8235573, the static variable _last_sweep in objectSampler.cpp can be modified and read concurrently. For 64 bit platforms, this isn't a problem but for 32 bit platforms that support concurrent weak reference processing, this could word tear. This change adds atomic accesses for said variable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251179 > Webrev: http://cr.openjdk.java.net/~mgronlun/8251179/webrev00/ > Testing: jdk_jfr > > Thank you > Markus From david.holmes at oracle.com Thu Aug 6 23:07:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Aug 2020 09:07:19 +1000 Subject: RFR(XS): 8251179: Word tearing problem with _last_sweep In-Reply-To: <758d5dfb-1f08-233c-1d21-4c465eaf1cd0@oracle.com> References: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> <758d5dfb-1f08-233c-1d21-4c465eaf1cd0@oracle.com> Message-ID: +1 Thanks, David On 7/08/2020 8:20 am, Coleen Phillimore wrote: > > This looks good to me.? Thank you for fixing this! > Coleen > > On 8/6/20 6:09 PM, Markus Gronlund wrote: >> Greetings, >> >> This is a follow-up to 8235573: Move JFR ObjectSample oop into >> OopStorage. >> >> As of JDK-8235573, the static variable _last_sweep in >> objectSampler.cpp can be modified and read concurrently. For 64 bit >> platforms, this isn't a problem but for 32 bit platforms that support >> concurrent weak reference processing, this could word tear. This >> change adds atomic accesses for said variable. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8251179 >> Webrev: http://cr.openjdk.java.net/~mgronlun/8251179/webrev00/ >> Testing: jdk_jfr >> >> Thank you >> Markus > From kim.barrett at oracle.com Thu Aug 6 23:47:20 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 6 Aug 2020 19:47:20 -0400 Subject: RFR(XS): 8251179: Word tearing problem with _last_sweep In-Reply-To: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> References: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> Message-ID: > On Aug 6, 2020, at 6:09 PM, Markus Gronlund wrote: > > Greetings, > > This is a follow-up to 8235573: Move JFR ObjectSample oop into OopStorage. > > As of JDK-8235573, the static variable _last_sweep in objectSampler.cpp can be modified and read concurrently. For 64 bit platforms, this isn't a problem but for 32 bit platforms that support concurrent weak reference processing, this could word tear. This change adds atomic accesses for said variable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251179 > Webrev: http://cr.openjdk.java.net/~mgronlun/8251179/webrev00/ > Testing: jdk_jfr > > Thank you > Markus Looks good. From erik.osterlund at oracle.com Fri Aug 7 06:49:48 2020 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Fri, 7 Aug 2020 08:49:48 +0200 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <34a579bb-281e-3c27-7526-eead98555421@oracle.com> References: <34a579bb-281e-3c27-7526-eead98555421@oracle.com> Message-ID: <0E04F702-41EE-426E-8143-56E82AC58932@oracle.com> Hi Coleen, Thanks for fixing the asserts. Looks good. /Erik > On 6 Aug 2020, at 20:39, Coleen Phillimore wrote: > > ? > >> On 8/6/20 10:39 AM, Coleen Phillimore wrote: >> >> >>> On 8/6/20 9:45 AM, Erik ?sterlund wrote: >>> Hi Coleen, >>> >>> I think this looks good. >>> >>> One nit. In the C1 code, the first load should be T_ADDRESS instead of T_METADATA. >>> Don't need another webrev for that. >> >> Thanks Erik. I'll fix that. > > Unfortunately, this change ran into an assert that I had to make accept T_ADDRESS. After that c1 works fine. > > http://cr.openjdk.java.net/~coleenp/2020/8244997.02.incr/webrev/index.html > > Reran tier1 tests on Oracle platforms, and cross compiled on linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. > > Thanks, > Coleen > >> Coleen >> >>> >>> Thanks, >>> /Erik >>> >>> On 2020-08-06 14:40, Coleen Phillimore wrote: >>>> Summary: Move the oop and handle releasing it in the service thread. Remove Universe::oops_do from callers. >>>> >>>> See bug for more details and discussion. C2 code provided by Erik Osterlund and Graal changes provided by Tom Rodriguez. >>>> >>>> Tested with tiers 1-8. >>>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >>>> >>>> Copyrights fixed, not in this webrev. >>>> >>>> Thanks, >>>> Coleen >>> >> > From kim.barrett at oracle.com Fri Aug 7 08:33:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Aug 2020 04:33:06 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters Message-ID: Please review this change which adds some utility alias templates for function template SFINAE via additional non-type template parameters with default values. These aliases can also be used for class template SFINAE with a small change to current usage. With C++98/03 there are two ways to use enable_if with function templates: (1) As the return type (2) As an extra parameter Both are syntactically messy, polluting the function signature. C++11 adds a third way, using an extra anonymous non-type template parameter with a default value, i.e. // This overload is only considered when T is an integral type. template::value, int> = 0> void foo(T x) { ... } There's still a lot of syntactic noise in that, but we can substantially reduce the noise using alias templates. With the proposed utilities, that can be written as // This overload is only considered when T is an integral type. template> = 0> void foo(T x) { ... } The trailing " = 0" is a small remaining syntactic annoyance. That can't be eliminated without the use of macros though. While I like macros, this didn't seem to me to rise to the level of being worth using them. There are four new aliases: template EnableIfX; // int if V, else error. template EnableIfT; // int if T::value, else error. template EnableIfAnd; // int if Conjunction::value, else error. template EnableIfOr; // int if Disjunction::value, else error. I'm open to bikeshedding on the names of EnableIfX and EnableIfT. (I'm disappointed that there's even a need for the distinction between EnableIfX and EnableIfT. A macro can completely hide that distinction (along with the conventional " = 0" default value if desired). Unfortunately, the implementation of such a macro foundered on MSVC bugs that I was unable to work around. To be fair, my preferred implementation also ICE'd gcc.) CR: https://bugs.openjdk.java.net/browse/JDK-8251274 Webrev: https://cr.openjdk.java.net/~kbarrett/8251274/open.00/ Testing: tier1, along with conversion of some existing code to use the new mechanism. From markus.gronlund at oracle.com Fri Aug 7 09:20:22 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 7 Aug 2020 02:20:22 -0700 (PDT) Subject: RFR(XS): 8251179: Word tearing problem with _last_sweep In-Reply-To: <758d5dfb-1f08-233c-1d21-4c465eaf1cd0@oracle.com> References: <214ca010-9876-4ff1-a9c6-a03397aa7d3a@default> <758d5dfb-1f08-233c-1d21-4c465eaf1cd0@oracle.com> Message-ID: Coleen, David and Kim, Thank you for your reviews! Markus -----Original Message----- From: Coleen Phillimore Sent: den 7 augusti 2020 00:20 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8251179: Word tearing problem with _last_sweep This looks good to me.? Thank you for fixing this! Coleen On 8/6/20 6:09 PM, Markus Gronlund wrote: > Greetings, > > This is a follow-up to 8235573: Move JFR ObjectSample oop into OopStorage. > > As of JDK-8235573, the static variable _last_sweep in objectSampler.cpp can be modified and read concurrently. For 64 bit platforms, this isn't a problem but for 32 bit platforms that support concurrent weak reference processing, this could word tear. This change adds atomic accesses for said variable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251179 > Webrev: http://cr.openjdk.java.net/~mgronlun/8251179/webrev00/ > Testing: jdk_jfr > > Thank you > Markus From coleen.phillimore at oracle.com Fri Aug 7 11:51:28 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 7 Aug 2020 07:51:28 -0400 Subject: RFR (L) 8244997: Convert the JavaThread::_threadObj oop to use OopStorage In-Reply-To: <0E04F702-41EE-426E-8143-56E82AC58932@oracle.com> References: <34a579bb-281e-3c27-7526-eead98555421@oracle.com> <0E04F702-41EE-426E-8143-56E82AC58932@oracle.com> Message-ID: Thank you Erik and thanks for your help! Coleen On 8/7/20 2:49 AM, Erik ?sterlund wrote: > Hi Coleen, > > Thanks for fixing the asserts. Looks good. > > /Erik > >> On 6 Aug 2020, at 20:39, Coleen Phillimore wrote: >> >> ? >> >>> On 8/6/20 10:39 AM, Coleen Phillimore wrote: >>> >>> >>>> On 8/6/20 9:45 AM, Erik ?sterlund wrote: >>>> Hi Coleen, >>>> >>>> I think this looks good. >>>> >>>> One nit. In the C1 code, the first load should be T_ADDRESS instead of T_METADATA. >>>> Don't need another webrev for that. >>> Thanks Erik. I'll fix that. >> Unfortunately, this change ran into an assert that I had to make accept T_ADDRESS. After that c1 works fine. >> >> http://cr.openjdk.java.net/~coleenp/2020/8244997.02.incr/webrev/index.html >> >> Reran tier1 tests on Oracle platforms, and cross compiled on linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >> >> Thanks, >> Coleen >> >>> Coleen >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2020-08-06 14:40, Coleen Phillimore wrote: >>>>> Summary: Move the oop and handle releasing it in the service thread. Remove Universe::oops_do from callers. >>>>> >>>>> See bug for more details and discussion. C2 code provided by Erik Osterlund and Graal changes provided by Tom Rodriguez. >>>>> >>>>> Tested with tiers 1-8. >>>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8244997 >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8244997.01/webrev >>>>> >>>>> Copyrights fixed, not in this webrev. >>>>> >>>>> Thanks, >>>>> Coleen From kim.barrett at oracle.com Sun Aug 9 07:44:45 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 9 Aug 2020 03:44:45 -0400 Subject: RFR: 8251322: Improve BitMap::iterate Message-ID: Please review this improvement to BitMap::iterate. The code is both simplified and made more performant by using get_next_one_bit to scan the bitmap. Making it inline may allow the compiler to devirtualize and possibly inline the closure invocation. These changes result in some configurations executing ~1M fewer instructions during startup. CR: https://bugs.openjdk.java.net/browse/JDK-8251322 Webrev: https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ Testing: mach5 tier1-3. Used Linux-x64 perf on java -version to examine startup impact. From thomas.stuefe at gmail.com Sun Aug 9 09:26:19 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 9 Aug 2020 11:26:19 +0200 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: References: Message-ID: Hi Kim, LGTM ..Thomas On Sun, Aug 9, 2020 at 9:46 AM Kim Barrett wrote: > Please review this improvement to BitMap::iterate. The code is both > simplified and made more performant by using get_next_one_bit to scan > the bitmap. Making it inline may allow the compiler to devirtualize > and possibly inline the closure invocation. These changes result in > some configurations executing ~1M fewer instructions during startup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251322 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ > > Testing: > mach5 tier1-3. > Used Linux-x64 perf on java -version to examine startup impact. > > > From kim.barrett at oracle.com Sun Aug 9 09:32:23 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 9 Aug 2020 05:32:23 -0400 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: References: Message-ID: > On Aug 9, 2020, at 5:26 AM, Thomas St?fe wrote: > > Hi Kim, > > LGTM Thanks. > > ..Thomas > > On Sun, Aug 9, 2020 at 9:46 AM Kim Barrett wrote: > Please review this improvement to BitMap::iterate. The code is both > simplified and made more performant by using get_next_one_bit to scan > the bitmap. Making it inline may allow the compiler to devirtualize > and possibly inline the closure invocation. These changes result in > some configurations executing ~1M fewer instructions during startup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251322 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ > > Testing: > mach5 tier1-3. > Used Linux-x64 perf on java -version to examine startup impact. From david.holmes at oracle.com Mon Aug 10 04:24:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Aug 2020 14:24:37 +1000 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: References: Message-ID: <5bc095f2-80b7-731d-a9f8-a8cb00671b1f@oracle.com> Hi Kim, On 9/08/2020 5:44 pm, Kim Barrett wrote: > Please review this improvement to BitMap::iterate. The code is both > simplified and made more performant by using get_next_one_bit to scan > the bitmap. Making it inline may allow the compiler to devirtualize > and possibly inline the closure invocation. These changes result in > some configurations executing ~1M fewer instructions during startup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251322 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ The new code looks much clearer and simpler! Only one minor comment. The old code clearly documents the range as being right-open, whereas this: // Iteration support. Applies the closure to the index for each set bit, // starting from the least index in the range to the greatest, in order. does not clearly state so. Thanks, David ----- > Testing: > mach5 tier1-3. > Used Linux-x64 perf on java -version to examine startup impact. > > From kim.barrett at oracle.com Mon Aug 10 07:18:45 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 10 Aug 2020 03:18:45 -0400 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: <5bc095f2-80b7-731d-a9f8-a8cb00671b1f@oracle.com> References: <5bc095f2-80b7-731d-a9f8-a8cb00671b1f@oracle.com> Message-ID: <41AE0515-A20C-40A2-9FE6-6DCC2B26963B@oracle.com> > On Aug 10, 2020, at 12:24 AM, David Holmes wrote: > > Hi Kim, > > On 9/08/2020 5:44 pm, Kim Barrett wrote: >> Please review this improvement to BitMap::iterate. The code is both >> simplified and made more performant by using get_next_one_bit to scan >> the bitmap. Making it inline may allow the compiler to devirtualize >> and possibly inline the closure invocation. These changes result in >> some configurations executing ~1M fewer instructions during startup. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8251322 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ > > The new code looks much clearer and simpler! Only one minor comment. > The old code clearly documents the range as being right-open, whereas this: > > // Iteration support. Applies the closure to the index for each set bit, > // starting from the least index in the range to the greatest, in order. > > does not clearly state so. Throughout this class, ranges are half-open on the right. That isn?t always stated explicitly in description comments though. There?s even a verify_range function. There was some discussion a while ago about cleaning up some of the nomenclature and descriptions, but I haven?t gotten back to that yet. I?ve added ?// precondition: beg and end form a valid range.? to the iterate description. From thomas.schatzl at oracle.com Mon Aug 10 07:41:09 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 10 Aug 2020 09:41:09 +0200 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: References: Message-ID: Hi, On 09.08.20 09:44, Kim Barrett wrote: > Please review this improvement to BitMap::iterate. The code is both > simplified and made more performant by using get_next_one_bit to scan > the bitmap. Making it inline may allow the compiler to devirtualize > and possibly inline the closure invocation. These changes result in > some configurations executing ~1M fewer instructions during startup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251322 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ > > Testing: > mach5 tier1-3. > Used Linux-x64 perf on java -version to examine startup impact. > > lgtm. Thanks, Thomas From kim.barrett at oracle.com Mon Aug 10 10:50:57 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 10 Aug 2020 06:50:57 -0400 Subject: RFR: 8251322: Improve BitMap::iterate In-Reply-To: References: Message-ID: > On Aug 10, 2020, at 3:41 AM, Thomas Schatzl wrote: > > Hi, > > On 09.08.20 09:44, Kim Barrett wrote: >> Please review this improvement to BitMap::iterate. The code is both >> simplified and made more performant by using get_next_one_bit to scan >> the bitmap. Making it inline may allow the compiler to devirtualize >> and possibly inline the closure invocation. These changes result in >> some configurations executing ~1M fewer instructions during startup. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8251322 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8251322/open.00/ >> Testing: >> mach5 tier1-3. >> Used Linux-x64 perf on java -version to examine startup impact. > > lgtm. > > Thanks, > Thomas Thanks. From coleen.phillimore at oracle.com Mon Aug 10 19:37:08 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Aug 2020 15:37:08 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti Message-ID: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> These OopHandles are created and released during breakpoints and Thread stack walking operations.? They should have their own OopStorage so that GC can detect whether these things affect timing. Tested with tier1-6. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8251302 Thanks, Coleen From coleen.phillimore at oracle.com Mon Aug 10 21:28:59 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Aug 2020 17:28:59 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> Message-ID: <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: > On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> It looks good to me. >> Minor: >> +void JvmtiExport::initialize_oop_storage() { >> + // OopStorage needs to be created early in startup and unconditionally >> + // because of OopStorageSet static array indices. >> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread OopStorage"); >> +} >> + >> Would it better to replace "Thread Oopstorage" with "JVMTI OopStorage"? > > In the file > http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html > I see this: > "Thread OopStorage", > + "ThreadService OopStorage", > It is not clear if we can simply add ""JVMTI OopStorage" above. Serguei,? Thank you for finding this.? I was wondering why I didn't have to add JVMTI OopStorage to the test.? I'd cut/pasted the same string for Thread OopStorage. I'll fix this and the test and retest. thanks, Coleen > > Thanks, > Serguei > > >> No need in another webrev. >> >> Thanks, >> Serguei >> >> On 8/10/20 12:37, Coleen Phillimore wrote: >>> These OopHandles are created and released during breakpoints and >>> Thread stack walking operations.? They should have their own >>> OopStorage so that GC can detect whether these things affect timing. >>> >>> Tested with tier1-6. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Mon Aug 10 22:11:06 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Aug 2020 18:11:06 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> Message-ID: On 8/10/20 5:28 PM, Coleen Phillimore wrote: > > > On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> It looks good to me. >>> Minor: >>> +void JvmtiExport::initialize_oop_storage() { >>> + // OopStorage needs to be created early in startup and >>> unconditionally >>> + // because of OopStorageSet static array indices. >>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>> OopStorage"); >>> +} >>> + >>> Would it better to replace "Thread Oopstorage" with "JVMTI OopStorage"? >> >> In the file >> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >> >> I see this: >> ????????????? "Thread OopStorage", >> + "ThreadService OopStorage", >> It is not clear if we can simply add ""JVMTI OopStorage" above. > > Serguei,? Thank you for finding this.? I was wondering why I didn't > have to add JVMTI OopStorage to the test.? I'd cut/pasted the same > string for Thread OopStorage. > > I'll fix this and the test and retest. Hi Serguei, open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev This fixes the test as well. Thanks! Coleen > > thanks, > Coleen >> >> Thanks, >> Serguei >> >> >>> No need in another webrev. >>> >>> Thanks, >>> Serguei >>> >>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>> These OopHandles are created and released during breakpoints and >>>> Thread stack walking operations.? They should have their own >>>> OopStorage so that GC can detect whether these things affect timing. >>>> >>>> Tested with tier1-6. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>> >>>> Thanks, >>>> Coleen >>> >> > From coleen.phillimore at oracle.com Mon Aug 10 22:39:47 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Aug 2020 18:39:47 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> Message-ID: <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> Adding back serviceability-dev. Thanks for reviewing Serguei. Coleen On 8/10/20 6:11 PM, Coleen Phillimore wrote: > > > On 8/10/20 5:28 PM, Coleen Phillimore wrote: >> >> >> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> It looks good to me. >>>> Minor: >>>> +void JvmtiExport::initialize_oop_storage() { >>>> + // OopStorage needs to be created early in startup and >>>> unconditionally >>>> + // because of OopStorageSet static array indices. >>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>> OopStorage"); >>>> +} >>>> + >>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>> OopStorage"? >>> >>> In the file >>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>> >>> I see this: >>> ????????????? "Thread OopStorage", >>> + "ThreadService OopStorage", >>> It is not clear if we can simply add ""JVMTI OopStorage" above. >> >> Serguei,? Thank you for finding this.? I was wondering why I didn't >> have to add JVMTI OopStorage to the test.? I'd cut/pasted the same >> string for Thread OopStorage. >> >> I'll fix this and the test and retest. > > Hi Serguei, > > open webrev at > http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev > > This fixes the test as well. > > Thanks! > Coleen > >> >> thanks, >> Coleen >>> >>> Thanks, >>> Serguei >>> >>> >>>> No need in another webrev. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>> These OopHandles are created and released during breakpoints and >>>>> Thread stack walking operations.? They should have their own >>>>> OopStorage so that GC can detect whether these things affect timing. >>>>> >>>>> Tested with tier1-6. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Aug 10 23:19:10 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Aug 2020 16:19:10 -0700 Subject: [16] RFR (URGENT) 8251369: [JVMCI] Backout 8246347 changes Message-ID: <8e296404-84b0-9295-61b1-4f346d51f697@oracle.com> http://cr.openjdk.java.net/~kvn/8251369/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8251369 Backout 8246347 [1] changes because it cause a lot of Graal and AOT tests fail. Build and test (run AOT tests) it locally. Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8246347 From david.holmes at oracle.com Mon Aug 10 23:23:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Aug 2020 09:23:29 +1000 Subject: [16] RFR (URGENT) 8251369: [JVMCI] Backout 8246347 changes In-Reply-To: <8e296404-84b0-9295-61b1-4f346d51f697@oracle.com> References: <8e296404-84b0-9295-61b1-4f346d51f697@oracle.com> Message-ID: <75f8ed66-0791-3092-a347-58bef6773f29@oracle.com> Reviewed! Thanks, David On 11/08/2020 9:19 am, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8251369/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8251369 > > Backout 8246347 [1] changes because it cause a lot of Graal and AOT > tests fail. > > Build and test (run AOT tests) it locally. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8246347 From serguei.spitsyn at oracle.com Mon Aug 10 23:29:35 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Aug 2020 16:29:35 -0700 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> Message-ID: <02cf0c6f-120c-9c96-6193-2a10a7e26f6a@oracle.com> Coleen, The update looks good to me. Thanks, Serguei On 8/10/20 15:39, Coleen Phillimore wrote: > Adding back serviceability-dev. > Thanks for reviewing Serguei. > Coleen > > On 8/10/20 6:11 PM, Coleen Phillimore wrote: >> >> >> On 8/10/20 5:28 PM, Coleen Phillimore wrote: >>> >>> >>> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen, >>>>> >>>>> It looks good to me. >>>>> Minor: >>>>> +void JvmtiExport::initialize_oop_storage() { >>>>> + // OopStorage needs to be created early in startup and >>>>> unconditionally >>>>> + // because of OopStorageSet static array indices. >>>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>>> OopStorage"); >>>>> +} >>>>> + >>>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>>> OopStorage"? >>>> >>>> In the file >>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>>> >>>> I see this: >>>> ????????????? "Thread OopStorage", >>>> + "ThreadService OopStorage", >>>> It is not clear if we can simply add ""JVMTI OopStorage" above. >>> >>> Serguei,? Thank you for finding this.? I was wondering why I didn't >>> have to add JVMTI OopStorage to the test.? I'd cut/pasted the same >>> string for Thread OopStorage. >>> >>> I'll fix this and the test and retest. >> >> Hi Serguei, >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev >> >> This fixes the test as well. >> >> Thanks! >> Coleen >> >>> >>> thanks, >>> Coleen >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> No need in another webrev. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>>> These OopHandles are created and released during breakpoints and >>>>>> Thread stack walking operations.? They should have their own >>>>>> OopStorage so that GC can detect whether these things affect timing. >>>>>> >>>>>> Tested with tier1-6. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Aug 10 23:31:35 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Aug 2020 16:31:35 -0700 Subject: [16] RFR (URGENT) 8251369: [JVMCI] Backout 8246347 changes In-Reply-To: <75f8ed66-0791-3092-a347-58bef6773f29@oracle.com> References: <8e296404-84b0-9295-61b1-4f346d51f697@oracle.com> <75f8ed66-0791-3092-a347-58bef6773f29@oracle.com> Message-ID: <502a61f8-f0ba-06fb-8c88-954997938523@oracle.com> Thank you, David. Pushed. Vladimir K On 8/10/20 4:23 PM, David Holmes wrote: > Reviewed! > > Thanks, > David > > On 11/08/2020 9:19 am, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8251369/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8251369 >> >> Backout 8246347 [1] changes because it cause a lot of Graal and AOT tests fail. >> >> Build and test (run AOT tests) it locally. >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8246347 From david.holmes at oracle.com Tue Aug 11 00:04:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Aug 2020 10:04:43 +1000 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> Message-ID: Hi Coleen, This looks good to me too! Were the changes in src/hotspot/share/utilities/macros.hpp just for completeness? You don't seem to use the new macro. src/hotspot/share/runtime/init.cpp It seems a little odd having an explicit call to JvmtiExport::initialize_oop_storage() rather than that call being inside on of the other init functions. But I don't really see an appropriate place for it. I thought perhaps management_init as it seems to combine a few related things, but it isn't really the right place either. I was also a little unsure if this initialization point would always be early enough, but it seems the oop-storage can't be touched by anything until the live phase, so this seems okay. Though I was wondering whether it should be done in vm_init_globals after universe_oopstorage_init, to maintain the same initialization point as it currnetly has? Thanks, David ----- On 11/08/2020 8:39 am, Coleen Phillimore wrote: > Adding back serviceability-dev. > Thanks for reviewing Serguei. > Coleen > > On 8/10/20 6:11 PM, Coleen Phillimore wrote: >> >> >> On 8/10/20 5:28 PM, Coleen Phillimore wrote: >>> >>> >>> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen, >>>>> >>>>> It looks good to me. >>>>> Minor: >>>>> +void JvmtiExport::initialize_oop_storage() { >>>>> + // OopStorage needs to be created early in startup and >>>>> unconditionally >>>>> + // because of OopStorageSet static array indices. >>>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>>> OopStorage"); >>>>> +} >>>>> + >>>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>>> OopStorage"? >>>> >>>> In the file >>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>>> >>>> I see this: >>>> ????????????? "Thread OopStorage", >>>> + "ThreadService OopStorage", >>>> It is not clear if we can simply add ""JVMTI OopStorage" above. >>> >>> Serguei,? Thank you for finding this.? I was wondering why I didn't >>> have to add JVMTI OopStorage to the test.? I'd cut/pasted the same >>> string for Thread OopStorage. >>> >>> I'll fix this and the test and retest. >> >> Hi Serguei, >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev >> >> This fixes the test as well. >> >> Thanks! >> Coleen >> >>> >>> thanks, >>> Coleen >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> No need in another webrev. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>>> These OopHandles are created and released during breakpoints and >>>>>> Thread stack walking operations.? They should have their own >>>>>> OopStorage so that GC can detect whether these things affect timing. >>>>>> >>>>>> Tested with tier1-6. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Aug 11 00:48:04 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Aug 2020 20:48:04 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> Message-ID: <86edc516-a7e5-b9aa-1f17-80b53f26d57d@oracle.com> Hi David,? Thank you for reviewing. On 8/10/20 8:04 PM, David Holmes wrote: > Hi Coleen, > > This looks good to me too! > > Were the changes in src/hotspot/share/utilities/macros.hpp just for > completeness? You don't seem to use the new macro. It was left over from an earlier edit.? I reverted it. > > ?src/hotspot/share/runtime/init.cpp > > It seems a little odd having an explicit call to > JvmtiExport::initialize_oop_storage() rather than that call being > inside on of the other init functions. But I don't really see an > appropriate place for it. I thought perhaps management_init as it > seems to combine a few related things, but it isn't really the right > place either. management_init() isn't the right place for JVMTI.?? I could have added a jvmti_init() that calls JvmtiExport::initialize_oop_storage() but honestly I think this whole thing should be rewritten to call static functions rather than through these forward declarations.? There are other places that call qualified static initialization functions in this code and I think this should migrate to that. > I was also a little unsure if this initialization point would always > be early enough, but it seems the oop-storage can't be touched by > anything until the live phase, so this seems okay. Though I was > wondering whether it should be done in vm_init_globals after > universe_oopstorage_init, to maintain the same initialization point as > it currnetly has? There are no jvmti specific initializations in the short amount of initialization code between vm_init_globals and init_globals so I chose the later initialization because it worked, and the later initialization risks dragging more dependencies forward with it. Doing jvmti initialization in what looks like very early initialization doesn't seem appropriate.? And isn't needed for correctness. thanks, Coleen > > Thanks, > David > ----- > > > On 11/08/2020 8:39 am, Coleen Phillimore wrote: >> Adding back serviceability-dev. >> Thanks for reviewing Serguei. >> Coleen >> >> On 8/10/20 6:11 PM, Coleen Phillimore wrote: >>> >>> >>> On 8/10/20 5:28 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> It looks good to me. >>>>>> Minor: >>>>>> +void JvmtiExport::initialize_oop_storage() { >>>>>> + // OopStorage needs to be created early in startup and >>>>>> unconditionally >>>>>> + // because of OopStorageSet static array indices. >>>>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>>>> OopStorage"); >>>>>> +} >>>>>> + >>>>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>>>> OopStorage"? >>>>> >>>>> In the file >>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>>>> >>>>> I see this: >>>>> ????????????? "Thread OopStorage", >>>>> + "ThreadService OopStorage", >>>>> It is not clear if we can simply add ""JVMTI OopStorage" above. >>>> >>>> Serguei,? Thank you for finding this.? I was wondering why I didn't >>>> have to add JVMTI OopStorage to the test.? I'd cut/pasted the same >>>> string for Thread OopStorage. >>>> >>>> I'll fix this and the test and retest. >>> >>> Hi Serguei, >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev >>> >>> This fixes the test as well. >>> >>> Thanks! >>> Coleen >>> >>>> >>>> thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> No need in another webrev. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>>>> These OopHandles are created and released during breakpoints and >>>>>>> Thread stack walking operations.? They should have their own >>>>>>> OopStorage so that GC can detect whether these things affect >>>>>>> timing. >>>>>>> >>>>>>> Tested with tier1-6. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Aug 11 02:07:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Aug 2020 12:07:28 +1000 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <86edc516-a7e5-b9aa-1f17-80b53f26d57d@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> <86edc516-a7e5-b9aa-1f17-80b53f26d57d@oracle.com> Message-ID: <0ce2b90e-02b6-a4e8-f14f-522578a9e924@oracle.com> On 11/08/2020 10:48 am, Coleen Phillimore wrote: > > Hi David,? Thank you for reviewing. > > On 8/10/20 8:04 PM, David Holmes wrote: >> Hi Coleen, >> >> This looks good to me too! >> >> Were the changes in src/hotspot/share/utilities/macros.hpp just for >> completeness? You don't seem to use the new macro. > > It was left over from an earlier edit.? I reverted it. Okay. >> >> ?src/hotspot/share/runtime/init.cpp >> >> It seems a little odd having an explicit call to >> JvmtiExport::initialize_oop_storage() rather than that call being >> inside on of the other init functions. But I don't really see an >> appropriate place for it. I thought perhaps management_init as it >> seems to combine a few related things, but it isn't really the right >> place either. > > management_init() isn't the right place for JVMTI.?? I could have added > a jvmti_init() that calls JvmtiExport::initialize_oop_storage() but > honestly I think this whole thing should be rewritten to call static > functions rather than through these forward declarations.? There are > other places that call qualified static initialization functions in this > code and I think this should migrate to that. > >> I was also a little unsure if this initialization point would always >> be early enough, but it seems the oop-storage can't be touched by >> anything until the live phase, so this seems okay. Though I was >> wondering whether it should be done in vm_init_globals after >> universe_oopstorage_init, to maintain the same initialization point as >> it currnetly has? > > There are no jvmti specific initializations in the short amount of > initialization code between vm_init_globals and init_globals so I chose > the later initialization because it worked, and the later initialization > risks dragging more dependencies forward with it. Doing jvmti > initialization in what looks like very early initialization doesn't seem > appropriate.? And isn't needed for correctness. Okay. Thanks, David > thanks, > Coleen >> >> Thanks, >> David >> ----- >> >> >> On 11/08/2020 8:39 am, Coleen Phillimore wrote: >>> Adding back serviceability-dev. >>> Thanks for reviewing Serguei. >>> Coleen >>> >>> On 8/10/20 6:11 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 8/10/20 5:28 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> It looks good to me. >>>>>>> Minor: >>>>>>> +void JvmtiExport::initialize_oop_storage() { >>>>>>> + // OopStorage needs to be created early in startup and >>>>>>> unconditionally >>>>>>> + // because of OopStorageSet static array indices. >>>>>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>>>>> OopStorage"); >>>>>>> +} >>>>>>> + >>>>>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>>>>> OopStorage"? >>>>>> >>>>>> In the file >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>>>>> >>>>>> I see this: >>>>>> ????????????? "Thread OopStorage", >>>>>> + "ThreadService OopStorage", >>>>>> It is not clear if we can simply add ""JVMTI OopStorage" above. >>>>> >>>>> Serguei,? Thank you for finding this.? I was wondering why I didn't >>>>> have to add JVMTI OopStorage to the test.? I'd cut/pasted the same >>>>> string for Thread OopStorage. >>>>> >>>>> I'll fix this and the test and retest. >>>> >>>> Hi Serguei, >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev >>>> >>>> This fixes the test as well. >>>> >>>> Thanks! >>>> Coleen >>>> >>>>> >>>>> thanks, >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> No need in another webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>>>>> These OopHandles are created and released during breakpoints and >>>>>>>> Thread stack walking operations.? They should have their own >>>>>>>> OopStorage so that GC can detect whether these things affect >>>>>>>> timing. >>>>>>>> >>>>>>>> Tested with tier1-6. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Tue Aug 11 10:14:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Aug 2020 20:14:41 +1000 Subject: RFC: 8249585: Define a NoAsyncExceptionCheckVerifier utility Message-ID: <8913f9f7-d34a-fb0a-1c85-d3b85286bc1b@oracle.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8249585 webrev: http://cr.openjdk.java.net/~dholmes/8249585/webrev/ I've been working around async exception handling issues over the past couple of months and the question that keeps cropping up is "will this code path reach any code that might install a pending async exception?". So this is an attempt to create such a little utility. Similar to NoSafepointVerifier the NoAsyncExceptionCheckVerifier can be used to "ensure" that a section of code cannot lead to a check for, and thus installation of, a pending async exception. The actual code the for NAECV and the check is quite trivial. In addition the webrev shows a number of initial experiments with placing the NAECV in some interesting code paths: - when code will use the CHECK_AND_CLEAR macro to clear all exceptions - In this case async exceptions should not just be cleared, but if we know they can't be installed then we don't have to worry about them. - In the ThreadBlockInVM thread-state transition (entry and exit) - Locking a Mutex (less interesting but a low-level bit of functionality you may want to know is "safe" wrt. async exception processing) Please ignore the addition of the NoSafepointVerifier in src/hotspot/share/runtime/biasedLocking.cpp - that snuck into the initial webrev accidentally. Now this utility is only as good as the code coverage that is applied to it. We might run a thousand tests, that always follow the same code path from the NAECV and so it never fires. But that doesn't mean it can't fire. So we really want to hammer this in testing if we want to be confident that there really can't be any async exceptions and so we can code (in product mode) accordingly. So far I've tested the above with tier 1-3 and with tiers 4-6 in progress. Now it may be that we can't use this to gain sufficient confidence to guide product mode code. Hence this is a RFC not RFR. This might just be an interesting experiment with no usable outcome outside individual experimentation. Comments welcome. Thanks, David From coleen.phillimore at oracle.com Tue Aug 11 11:28:01 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 07:28:01 -0400 Subject: RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti In-Reply-To: <0ce2b90e-02b6-a4e8-f14f-522578a9e924@oracle.com> References: <3493f679-c5e2-9f05-4bfa-aaab1543361d@oracle.com> <49934bad-680d-121b-a1e5-56b9cd42d4a0@oracle.com> <024599a2-6c5d-98e0-8f26-bfe183e9c474@oracle.com> <36dc666d-f12c-0250-9b65-4794f05641db@oracle.com> <20c3370f-ae8c-aadc-53b1-95db92776f31@oracle.com> <86edc516-a7e5-b9aa-1f17-80b53f26d57d@oracle.com> <0ce2b90e-02b6-a4e8-f14f-522578a9e924@oracle.com> Message-ID: <1ef431be-152c-1d7d-4390-c0a21594c8cc@oracle.com> Thanks David! Coleen On 8/10/20 10:07 PM, David Holmes wrote: > On 11/08/2020 10:48 am, Coleen Phillimore wrote: >> >> Hi David,? Thank you for reviewing. >> >> On 8/10/20 8:04 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> This looks good to me too! >>> >>> Were the changes in src/hotspot/share/utilities/macros.hpp just for >>> completeness? You don't seem to use the new macro. >> >> It was left over from an earlier edit.? I reverted it. > > Okay. > >>> >>> ?src/hotspot/share/runtime/init.cpp >>> >>> It seems a little odd having an explicit call to >>> JvmtiExport::initialize_oop_storage() rather than that call being >>> inside on of the other init functions. But I don't really see an >>> appropriate place for it. I thought perhaps management_init as it >>> seems to combine a few related things, but it isn't really the right >>> place either. >> >> management_init() isn't the right place for JVMTI.?? I could have >> added a jvmti_init() that calls JvmtiExport::initialize_oop_storage() >> but honestly I think this whole thing should be rewritten to call >> static functions rather than through these forward declarations.? >> There are other places that call qualified static initialization >> functions in this code and I think this should migrate to that. >> >>> I was also a little unsure if this initialization point would always >>> be early enough, but it seems the oop-storage can't be touched by >>> anything until the live phase, so this seems okay. Though I was >>> wondering whether it should be done in vm_init_globals after >>> universe_oopstorage_init, to maintain the same initialization point >>> as it currnetly has? >> >> There are no jvmti specific initializations in the short amount of >> initialization code between vm_init_globals and init_globals so I >> chose the later initialization because it worked, and the later >> initialization risks dragging more dependencies forward with it. >> Doing jvmti initialization in what looks like very early >> initialization doesn't seem appropriate.? And isn't needed for >> correctness. > > Okay. > > Thanks, > David > >> thanks, >> Coleen >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 11/08/2020 8:39 am, Coleen Phillimore wrote: >>>> Adding back serviceability-dev. >>>> Thanks for reviewing Serguei. >>>> Coleen >>>> >>>> On 8/10/20 6:11 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 8/10/20 5:28 PM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> It looks good to me. >>>>>>>> Minor: >>>>>>>> +void JvmtiExport::initialize_oop_storage() { >>>>>>>> + // OopStorage needs to be created early in startup and >>>>>>>> unconditionally >>>>>>>> + // because of OopStorageSet static array indices. >>>>>>>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread >>>>>>>> OopStorage"); >>>>>>>> +} >>>>>>>> + >>>>>>>> Would it better to replace "Thread Oopstorage" with "JVMTI >>>>>>>> OopStorage"? >>>>>>> >>>>>>> In the file >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html >>>>>>> >>>>>>> I see this: >>>>>>> ????????????? "Thread OopStorage", >>>>>>> + "ThreadService OopStorage", >>>>>>> It is not clear if we can simply add ""JVMTI OopStorage" above. >>>>>> >>>>>> Serguei,? Thank you for finding this.? I was wondering why I >>>>>> didn't have to add JVMTI OopStorage to the test. I'd cut/pasted >>>>>> the same string for Thread OopStorage. >>>>>> >>>>>> I'll fix this and the test and retest. >>>>> >>>>> Hi Serguei, >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.02.incr/webrev >>>>> >>>>> This fixes the test as well. >>>>> >>>>> Thanks! >>>>> Coleen >>>>> >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> No need in another webrev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 8/10/20 12:37, Coleen Phillimore wrote: >>>>>>>>> These OopHandles are created and released during breakpoints >>>>>>>>> and Thread stack walking operations.? They should have their >>>>>>>>> own OopStorage so that GC can detect whether these things >>>>>>>>> affect timing. >>>>>>>>> >>>>>>>>> Tested with tier1-6. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From coleen.phillimore at oracle.com Tue Aug 11 11:40:50 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 07:40:50 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 Message-ID: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Summary: Release OopStorage oops outside a safepoint. Tested with tier1-6. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8251336 Thank you to Zhengyu for alerting me about this issue. Coleen From zgu at redhat.com Tue Aug 11 12:39:14 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Aug 2020 08:39:14 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: <43cbb045-1dcd-62c6-91ad-ab7f279542cd@redhat.com> Hi Coleen, Thanks for the quick fix. Changes look good to me and Shenandoah tests also look good. -Zhengyu On 8/11/20 7:40 AM, Coleen Phillimore wrote: > Summary: Release OopStorage oops outside a safepoint. > > Tested with tier1-6. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > > Thank you to Zhengyu for alerting me about this issue. > > Coleen > From david.holmes at oracle.com Tue Aug 11 13:35:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Aug 2020 23:35:00 +1000 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: Hi Coleen, On 11/08/2020 9:40 pm, Coleen Phillimore wrote: > Summary: Release OopStorage oops outside a safepoint. > > Tested with tier1-6. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > > Thank you to Zhengyu for alerting me about this issue. Yeah ... I was focusing on the locking aspect and completely overlooked the fact that section of code is within the scope of the TBIVM. Not that it would have immediately rung any alarm bells. Do we have usage rules about manipulating OopStorage at a safepoint? If some GC's can't cope with it then there should be some detection of that in the OopStorage APIs. 71 static void release_oop_handles(OopHandleList* handles) { 72 MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); release_oop_handles doesn't need to grab the Service_lock as it doesn't touch any shared state. Otherwise fix looks fine. Thanks, David > Coleen From kim.barrett at oracle.com Tue Aug 11 13:56:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Aug 2020 09:56:15 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: > On Aug 11, 2020, at 7:40 AM, Coleen Phillimore wrote: > > Summary: Release OopStorage oops outside a safepoint. > > Tested with tier1-6. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > > Thank you to Zhengyu for alerting me about this issue. > > Coleen ------------------------------------------------------------------------------ src/hotspot/share/runtime/serviceThread.cpp 240 oop_handles_to_release = NULL; This line isn't needed. We're going to exit the scope of that variable. But see below. ------------------------------------------------------------------------------ src/hotspot/share/runtime/serviceThread.cpp 184 // The ServiceThread is blocked here so runs during a safepoint. This comment doesn't make any sense to me. This *is* the ServiceThread, so to be executing this code it's clearly *not* blocked in any usual sense of that word. I think more accurate is that it's marked as _thread_blocked, so could be running during a safepoint. But see below. ------------------------------------------------------------------------------ src/hotspot/share/runtime/serviceThread.cpp 72 MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); release_oop_handles isn't manipulating any shared state, so doesn't need any locking. And that's good, because we'd rather not be holding it across the list deletion. But see below. [And I see David mentioned this too.] ------------------------------------------------------------------------------ src/hotspot/share/runtime/serviceThread.cpp I think more in keeping with the style elsewhere in this code would be to just have a boolean flag that there are handles to process, and to have release_oop_handles briefly take the Service_lock (again) to grab the current list. Doing so would eliminate the code related to the first two comments above, and change things for the third. The cost is a brief extra grab of Service_lock in the presumably uncommon situation where there are list entries to deal with. You're call. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Aug 11 13:58:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Aug 2020 09:58:27 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: <2C7D2ABA-A389-4DFC-AE42-D3BA0997E2F9@oracle.com> > On Aug 11, 2020, at 9:56 AM, Kim Barrett wrote: > >> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore wrote: >> >> Summary: Release OopStorage oops outside a safepoint. >> >> Tested with tier1-6. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >> >> Thank you to Zhengyu for alerting me about this issue. >> >> Coleen BTW, I haven?t actually looked, but I think there?s a good chance this also affects G1. From coleen.phillimore at oracle.com Tue Aug 11 14:08:47 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 10:08:47 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <43cbb045-1dcd-62c6-91ad-ab7f279542cd@redhat.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <43cbb045-1dcd-62c6-91ad-ab7f279542cd@redhat.com> Message-ID: <10c4c264-4557-c936-5c5b-5304ad0ff624@oracle.com> On 8/11/20 8:39 AM, Zhengyu Gu wrote: > Hi Coleen, > > Thanks for the quick fix. > > Changes look good to me and Shenandoah tests also look good. Thank you Zhengyu.? Thanks for verifying with the Shenandoah tests. Coleen > > -Zhengyu > > On 8/11/20 7:40 AM, Coleen Phillimore wrote: >> Summary: Release OopStorage oops outside a safepoint. >> >> Tested with tier1-6. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >> >> Thank you to Zhengyu for alerting me about this issue. >> >> Coleen >> > From coleen.phillimore at oracle.com Tue Aug 11 14:11:49 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 10:11:49 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: <62619942-0e5c-3257-611e-6934a1290981@oracle.com> On 8/11/20 9:35 AM, David Holmes wrote: > Hi Coleen, > > On 11/08/2020 9:40 pm, Coleen Phillimore wrote: >> Summary: Release OopStorage oops outside a safepoint. >> >> Tested with tier1-6. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >> >> Thank you to Zhengyu for alerting me about this issue. > > Yeah ... I was focusing on the locking aspect and completely > overlooked the fact that section of code is within the scope of the > TBIVM. Not that it would have immediately rung any alarm bells. Yes, it escaped me that TBIVM marks the thread as _thread_blocked so safe in a safepoint.? I thought if release were not ok there, I would have seen some sort of crash. > > Do we have usage rules about manipulating OopStorage at a safepoint? > If some GC's can't cope with it then there should be some detection of > that in the OopStorage APIs. I don't know this. > > ? 71 static void release_oop_handles(OopHandleList* handles) { > ? 72?? MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > release_oop_handles? doesn't need to grab the Service_lock as it > doesn't touch any shared state. Oh, yes, you are right.? I can remove the lock. Thanks, Coleen > > Otherwise fix looks fine. > > Thanks, > David > >> Coleen From coleen.phillimore at oracle.com Tue Aug 11 14:15:14 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 10:15:14 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: On 8/11/20 9:56 AM, Kim Barrett wrote: >> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore wrote: >> >> Summary: Release OopStorage oops outside a safepoint. >> >> Tested with tier1-6. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >> >> Thank you to Zhengyu for alerting me about this issue. >> >> Coleen > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/serviceThread.cpp > 240 oop_handles_to_release = NULL; > > This line isn't needed. We're going to exit the scope of that variable. > But see below. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/serviceThread.cpp > 184 // The ServiceThread is blocked here so runs during a safepoint. > > This comment doesn't make any sense to me. This *is* the > ServiceThread, so to be executing this code it's clearly *not* blocked > in any usual sense of that word. > > I think more accurate is that it's marked as _thread_blocked, so could > be running during a safepoint. > > But see below. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/serviceThread.cpp > 72 MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); > > release_oop_handles isn't manipulating any shared state, so doesn't > need any locking. And that's good, because we'd rather not be holding > it across the list deletion. > > But see below. > > [And I see David mentioned this too.] > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/serviceThread.cpp > > I think more in keeping with the style elsewhere in this code would be > to just have a boolean flag that there are handles to process, and to > have release_oop_handles briefly take the Service_lock (again) to grab > the current list. Doing so would eliminate the code related to the > first two comments above, and change things for the third. > > The cost is a brief extra grab of Service_lock in the presumably > uncommon situation where there are list entries to deal with. This style matches the jvmti code, but sure, I could change it like this.? Then I don't need the temporary list. thanks, Coleen > > You're call. > > ------------------------------------------------------------------------------ > From shade at redhat.com Tue Aug 11 14:15:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 11 Aug 2020 16:15:38 +0200 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <2C7D2ABA-A389-4DFC-AE42-D3BA0997E2F9@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <2C7D2ABA-A389-4DFC-AE42-D3BA0997E2F9@oracle.com> Message-ID: On 8/11/20 3:58 PM, Kim Barrett wrote: >> On Aug 11, 2020, at 9:56 AM, Kim Barrett wrote: >> >>> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore wrote: >>> >>> Summary: Release OopStorage oops outside a safepoint. >>> >>> Tested with tier1-6. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>> >>> Thank you to Zhengyu for alerting me about this issue. >>> >>> Coleen > > BTW, I haven?t actually looked, but I think there?s a good chance this also affects G1. Yes, it does not look Shenandoah-specific. The failure is on the NativeAccess::oop_store/SATB path. It reproduces with Shenandoah because it has lots of asserts on SATB paths, it sometimes calls enqueue with NULL oops (which accidentally what is being passed there as "old" value), it has a very aggressive test that exercises destroyed threads (which had a fair share of baldness-inducing Shenandoah-specific bugs before, thus named gc/shenandoah/TestEvilSyncBug.java). Coleen, you might consider changing the synopsis a bit :) -- Thanks, -Aleksey From coleen.phillimore at oracle.com Tue Aug 11 14:29:47 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 10:29:47 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <2C7D2ABA-A389-4DFC-AE42-D3BA0997E2F9@oracle.com> Message-ID: <2b879f5c-24df-4ea0-b02a-65c31dff01ca@oracle.com> On 8/11/20 10:15 AM, Aleksey Shipilev wrote: > On 8/11/20 3:58 PM, Kim Barrett wrote: >>> On Aug 11, 2020, at 9:56 AM, Kim Barrett wrote: >>> >>>> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore wrote: >>>> >>>> Summary: Release OopStorage oops outside a safepoint. >>>> >>>> Tested with tier1-6. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>>> >>>> Thank you to Zhengyu for alerting me about this issue. >>>> >>>> Coleen >> BTW, I haven?t actually looked, but I think there?s a good chance this also affects G1. > Yes, it does not look Shenandoah-specific. The failure is on the NativeAccess::oop_store/SATB path. > > It reproduces with Shenandoah because it has lots of asserts on SATB paths, it sometimes calls > enqueue with NULL oops (which accidentally what is being passed there as "old" value), it has a very > aggressive test that exercises destroyed threads (which had a fair share of baldness-inducing > Shenandoah-specific bugs before, thus named gc/shenandoah/TestEvilSyncBug.java). > > Coleen, you might consider changing the synopsis a bit :) Ok, I will. Coleen > From coleen.phillimore at oracle.com Tue Aug 11 14:41:11 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 10:41:11 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> Kim's suggestion for this change looks really good.? I'm re-testing this now: open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8251336 New title: 8251336: OopHandle release can not be called in a safepoint Summary: Release OopStorage oops for threadObj for exiting threads outside the service lock region that is marked as safe for safepoint. Thanks, Coleen On 8/11/20 10:15 AM, Coleen Phillimore wrote: > > > On 8/11/20 9:56 AM, Kim Barrett wrote: >>> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore >>> wrote: >>> >>> Summary: Release OopStorage oops outside a safepoint. >>> >>> Tested with tier1-6. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>> >>> Thank you to Zhengyu for alerting me about this issue. >>> >>> Coleen >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/runtime/serviceThread.cpp >> ? 240?????? oop_handles_to_release = NULL; >> >> This line isn't needed.? We're going to exit the scope of that variable. >> But see below. >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/runtime/serviceThread.cpp >> ? 184?????? // The ServiceThread is blocked here so runs during a >> safepoint. >> >> This comment doesn't make any sense to me.? This *is* the >> ServiceThread, so to be executing this code it's clearly *not* blocked >> in any usual sense of that word. >> >> I think more accurate is that it's marked as _thread_blocked, so could >> be running during a safepoint. >> >> But see below. >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/runtime/serviceThread.cpp >> ?? 72?? MutexLocker ml(Service_lock, Mutex::_no_safepoint_check_flag); >> >> release_oop_handles isn't manipulating any shared state, so doesn't >> need any locking.? And that's good, because we'd rather not be holding >> it across the list deletion. >> >> But see below. >> >> [And I see David mentioned this too.] >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/runtime/serviceThread.cpp >> >> I think more in keeping with the style elsewhere in this code would be >> to just have a boolean flag that there are handles to process, and to >> have release_oop_handles briefly take the Service_lock (again) to grab >> the current list.? Doing so would eliminate the code related to the >> first two comments above, and change things for the third. >> >> The cost is a brief extra grab of Service_lock in the presumably >> uncommon situation where there are list entries to deal with. > > This style matches the jvmti code, but sure, I could change it like > this.? Then I don't need the temporary list. > > thanks, > Coleen >> >> You're call. >> >> ------------------------------------------------------------------------------ >> >> > From rkennke at redhat.com Tue Aug 11 14:42:32 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 11 Aug 2020 16:42:32 +0200 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: On Tue, 2020-08-11 at 23:35 +1000, David Holmes wrote: > Hi Coleen, > > On 11/08/2020 9:40 pm, Coleen Phillimore wrote: > > Summary: Release OopStorage oops outside a safepoint. > > > > Tested with tier1-6. > > > > open webrev at > > http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev > > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > > > > Thank you to Zhengyu for alerting me about this issue. > > Yeah ... I was focusing on the locking aspect and completely > overlooked > the fact that section of code is within the scope of the TBIVM. Not > that > it would have immediately rung any alarm bells. > > Do we have usage rules about manipulating OopStorage at a safepoint? > If > some GC's can't cope with it then there should be some detection of > that > in the OopStorage APIs. In general, non-GC threads should not mess with GC roots (e.g. OopStorage) during safepoints. I don't think that this plays well with any GC. Not sure if it can be automatically detected, it sure would be nice if that would fire an assert or so. Roman From kim.barrett at oracle.com Tue Aug 11 17:48:23 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Aug 2020 13:48:23 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> Message-ID: <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> > On Aug 11, 2020, at 10:41 AM, Coleen Phillimore wrote: > > > Kim's suggestion for this change looks really good. I'm re-testing this now: > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 In release_oop_handles, because Service_lock is a "special" lock and touched in lots of places, I'd prefer the deletion not happen under the lock. (I realize this uglifies the code a little bit.) Other than that, this looks good. From mandy.chung at oracle.com Tue Aug 11 18:00:40 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 11 Aug 2020 11:00:40 -0700 Subject: Review Request JDK-8244090: public lookup should find public members of public exported types In-Reply-To: <090cff25-2f48-d55f-721d-38acda80029b@oracle.com> References: <090cff25-2f48-d55f-721d-38acda80029b@oracle.com> Message-ID: <45df07ad-dd1f-6f20-8cfd-8152f7ce111b@oracle.com> It was agreed in an offline discussion with Lois, Kim and John that this work should wait for the integration of JDK-8247938 and JEP 347 Enable C++ 14 features. This patch is updated to use scoped enum consistent with JDK-8247938. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.01/index.html Thanks Mandy On 6/18/20 2:12 PM, Mandy Chung wrote: > Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup > object on C with PUBLIC access which can be used to look up > unconditionally exported public types from the module of C. Such > lookup can only look up this C class defined by loader 1 but not > another class named "C" defined by loader 2. > > JDK-8173978 adds the support for cross-module teleporting. > publicLookup().in(C.class) was changed to produce a public Lookup i.e. > with UNCONDITIONAL access.? A public lookup should be able to look up > public members of any unconditionally exported public types including > a class named "C" loaded by different loaders.? It reveals a bug in VM > resolution for Lookup API that adds the loader constraints with > java.lang.Object as the accessor that constraints a public lookup to > load one type named C but any more. > > The lookup class of a public lookup is irrelevant to the lookup > context.? Type consistency on P/Q/R live Class objects from the given > MethodType (MT)is ensured at the following: > 1. P/Q/R are consistent from the loader of the declaring class of the > resolved member (D's loader) > 2. P/Q/R are consistent w.r.t. the invoking class and the caller's MT > at invocation time (the method handle carries the caller's MT that > will be verified). > > The loader constraints added for public lookup is not necessary and > adds undesirable constraints.? The proposed fixis to skip adding > loader constraints if the lookup mode is either TRUSTED or UNCONDITIONAL. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.00/index.html > > > Thanks > Mandy From Monica.Beckwith at microsoft.com Tue Aug 11 18:15:24 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 11 Aug 2020 18:15:24 +0000 Subject: Collaboration proposal: Draft JEP MacOS/AArch64 Port Message-ID: Hello everyone,? It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? . Testing (all?regression,?functional, integration?and performance?tests)? . Integration to?jdk/jdk?(tip)? Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? Thanks,? Monica [1] http://openjdk.java.net/jeps/8251280 [2] https://developer.apple.com/programs/universal/ [3] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide [4] http://openjdk.java.net/projects/#new-project From coleen.phillimore at oracle.com Tue Aug 11 20:45:21 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 16:45:21 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> Message-ID: <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> On 8/11/20 1:48 PM, Kim Barrett wrote: >> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore wrote: >> >> >> Kim's suggestion for this change looks really good. I'm re-testing this now: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > In release_oop_handles, because Service_lock is a "special" lock and > touched in lots of places, I'd prefer the deletion not happen under > the lock. (I realize this uglifies the code a little bit.) Because there was no performance reason to use lock free code for this, I add to and clean out the linked list under the Service_lock.? I chose a simple implementation because there was no performance or correctness issue to do otherwise. I'd rather not change this to be ugly unless it's proven to not be correct or performant. thanks, Coleen > > Other than that, this looks good. > From coleen.phillimore at oracle.com Tue Aug 11 21:02:09 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 17:02:09 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> Message-ID: <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> On 8/11/20 4:45 PM, Coleen Phillimore wrote: > > > On 8/11/20 1:48 PM, Kim Barrett wrote: >>> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore >>> wrote: >>> >>> >>> Kim's suggestion for this change looks really good.? I'm re-testing >>> this now: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >> In release_oop_handles, because Service_lock is a "special" lock and >> touched in lots of places, I'd prefer the deletion not happen under >> the lock.? (I realize this uglifies the code a little bit.) > > Because there was no performance reason to use lock free code for > this, I add to and clean out the linked list under the Service_lock.? > I chose a simple implementation because there was no performance or > correctness issue to do otherwise. > > I'd rather not change this to be ugly unless it's proven to not be > correct or performant. Scratch that.? I see what you mean. Like: http://cr.openjdk.java.net/~coleenp/2020/8251336.03.incr/webrev/index.html (sorry I had some other questions about making this lock free). I'm re-testing this version now. Thanks, Coleen > > thanks, > Coleen > >> >> Other than that, this looks good. >> > From david.holmes at oracle.com Tue Aug 11 22:00:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Aug 2020 08:00:02 +1000 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> Message-ID: <471e77e7-226c-6c3e-beb5-0d354640947b@oracle.com> On 12/08/2020 7:02 am, Coleen Phillimore wrote: > > > On 8/11/20 4:45 PM, Coleen Phillimore wrote: >> >> >> On 8/11/20 1:48 PM, Kim Barrett wrote: >>>> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore >>>> wrote: >>>> >>>> >>>> Kim's suggestion for this change looks really good.? I'm re-testing >>>> this now: >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>> In release_oop_handles, because Service_lock is a "special" lock and >>> touched in lots of places, I'd prefer the deletion not happen under >>> the lock.? (I realize this uglifies the code a little bit.) >> >> Because there was no performance reason to use lock free code for >> this, I add to and clean out the linked list under the Service_lock. I >> chose a simple implementation because there was no performance or >> correctness issue to do otherwise. >> >> I'd rather not change this to be ugly unless it's proven to not be >> correct or performant. > > Scratch that.? I see what you mean. Like: > > http://cr.openjdk.java.net/~coleenp/2020/8251336.03.incr/webrev/index.html Yep that looks good. General principle of locking is to always try to hold the lock for the minimal amount of time necessary. > (sorry I had some other questions about making this lock free). Given the service thread has to be notified about the presence of work there's no point in trying to make the access lock free, as we're going to be holding the lock anyway. Cheers, David > I'm re-testing this version now. > > Thanks, > Coleen >> >> thanks, >> Coleen >> >>> >>> Other than that, this looks good. >>> >> > From david.holmes at oracle.com Tue Aug 11 22:01:17 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Aug 2020 08:01:17 +1000 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> Message-ID: <77984197-f9d6-e1b7-728d-5f6a95430cb5@oracle.com> On 12/08/2020 12:42 am, Roman Kennke wrote: > On Tue, 2020-08-11 at 23:35 +1000, David Holmes wrote: >> Hi Coleen, >> >> On 11/08/2020 9:40 pm, Coleen Phillimore wrote: >>> Summary: Release OopStorage oops outside a safepoint. >>> >>> Tested with tier1-6. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>> >>> Thank you to Zhengyu for alerting me about this issue. >> >> Yeah ... I was focusing on the locking aspect and completely >> overlooked >> the fact that section of code is within the scope of the TBIVM. Not >> that >> it would have immediately rung any alarm bells. >> >> Do we have usage rules about manipulating OopStorage at a safepoint? >> If >> some GC's can't cope with it then there should be some detection of >> that >> in the OopStorage APIs. > > In general, non-GC threads should not mess with GC roots (e.g. > OopStorage) during safepoints. I don't think that this plays well with > any GC. Not sure if it can be automatically detected, it sure would be > nice if that would fire an assert or so. I will file a RFE for that. David ----- > Roman > > From rkennke at redhat.com Tue Aug 11 22:21:52 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 12 Aug 2020 00:21:52 +0200 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <77984197-f9d6-e1b7-728d-5f6a95430cb5@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <77984197-f9d6-e1b7-728d-5f6a95430cb5@oracle.com> Message-ID: <0434376ba863b30ae5455552204895e34f8937a9.camel@redhat.com> On Wed, 2020-08-12 at 08:01 +1000, David Holmes wrote: > On 12/08/2020 12:42 am, Roman Kennke wrote: > > On Tue, 2020-08-11 at 23:35 +1000, David Holmes wrote: > > > Hi Coleen, > > > > > > On 11/08/2020 9:40 pm, Coleen Phillimore wrote: > > > > Summary: Release OopStorage oops outside a safepoint. > > > > > > > > Tested with tier1-6. > > > > > > > > open webrev at > > > > http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev > > > > bug link https://bugs.openjdk.java.net/browse/JDK-8251336 > > > > > > > > Thank you to Zhengyu for alerting me about this issue. > > > > > > Yeah ... I was focusing on the locking aspect and completely > > > overlooked > > > the fact that section of code is within the scope of the TBIVM. > > > Not > > > that > > > it would have immediately rung any alarm bells. > > > > > > Do we have usage rules about manipulating OopStorage at a > > > safepoint? > > > If > > > some GC's can't cope with it then there should be some detection > > > of > > > that > > > in the OopStorage APIs. > > > > In general, non-GC threads should not mess with GC roots (e.g. > > OopStorage) during safepoints. I don't think that this plays well > > with > > any GC. Not sure if it can be automatically detected, it sure would > > be > > nice if that would fire an assert or so. > > I will file a RFE for that. In-fact, this current bug is kinda what we want, except that the assert that we've seen is buried in GC specific code while it should be generic, and was checking another specific invariant (which is violated more rarely: only when observing the race), while we should explicitely check that threads do not mess with GC roots. This can probably be achieved in the heap access layer somehow. Roman From coleen.phillimore at oracle.com Tue Aug 11 22:35:50 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 18:35:50 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <0434376ba863b30ae5455552204895e34f8937a9.camel@redhat.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <77984197-f9d6-e1b7-728d-5f6a95430cb5@oracle.com> <0434376ba863b30ae5455552204895e34f8937a9.camel@redhat.com> Message-ID: <79199531-82fa-bd6c-5bb6-a4c13b96cddc@oracle.com> On 8/11/20 6:21 PM, Roman Kennke wrote: > On Wed, 2020-08-12 at 08:01 +1000, David Holmes wrote: >> On 12/08/2020 12:42 am, Roman Kennke wrote: >>> On Tue, 2020-08-11 at 23:35 +1000, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 11/08/2020 9:40 pm, Coleen Phillimore wrote: >>>>> Summary: Release OopStorage oops outside a safepoint. >>>>> >>>>> Tested with tier1-6. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>>>> >>>>> Thank you to Zhengyu for alerting me about this issue. >>>> Yeah ... I was focusing on the locking aspect and completely >>>> overlooked >>>> the fact that section of code is within the scope of the TBIVM. >>>> Not >>>> that >>>> it would have immediately rung any alarm bells. >>>> >>>> Do we have usage rules about manipulating OopStorage at a >>>> safepoint? >>>> If >>>> some GC's can't cope with it then there should be some detection >>>> of >>>> that >>>> in the OopStorage APIs. >>> In general, non-GC threads should not mess with GC roots (e.g. >>> OopStorage) during safepoints. I don't think that this plays well >>> with >>> any GC. Not sure if it can be automatically detected, it sure would >>> be >>> nice if that would fire an assert or so. >> I will file a RFE for that. > In-fact, this current bug is kinda what we want, except that the assert > that we've seen is buried in GC specific code while it should be > generic, and was checking another specific invariant (which is violated > more rarely: only when observing the race), while we should explicitely > check that threads do not mess with GC roots. This can probably be > achieved in the heap access layer somehow. Yes, I would have appreciated an assert earlier.? Thanks for your comments and to @David for the RFE. Coleen > > Roman > > From coleen.phillimore at oracle.com Tue Aug 11 22:37:11 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Aug 2020 18:37:11 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <471e77e7-226c-6c3e-beb5-0d354640947b@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> <471e77e7-226c-6c3e-beb5-0d354640947b@oracle.com> Message-ID: <391efbe5-bf55-e56f-44ea-fcc5bfbc2f02@oracle.com> On 8/11/20 6:00 PM, David Holmes wrote: > On 12/08/2020 7:02 am, Coleen Phillimore wrote: >> >> >> On 8/11/20 4:45 PM, Coleen Phillimore wrote: >>> >>> >>> On 8/11/20 1:48 PM, Kim Barrett wrote: >>>>> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore >>>>> wrote: >>>>> >>>>> >>>>> Kim's suggestion for this change looks really good.? I'm >>>>> re-testing this now: >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>>> In release_oop_handles, because Service_lock is a "special" lock and >>>> touched in lots of places, I'd prefer the deletion not happen under >>>> the lock.? (I realize this uglifies the code a little bit.) >>> >>> Because there was no performance reason to use lock free code for >>> this, I add to and clean out the linked list under the Service_lock. >>> I chose a simple implementation because there was no performance or >>> correctness issue to do otherwise. >>> >>> I'd rather not change this to be ugly unless it's proven to not be >>> correct or performant. >> >> Scratch that.? I see what you mean. Like: >> >> http://cr.openjdk.java.net/~coleenp/2020/8251336.03.incr/webrev/index.html >> > > Yep that looks good. General principle of locking is to always try to > hold the lock for the minimal amount of time necessary. >> (sorry I had some other questions about making this lock free). > > Given the service thread has to be notified about the presence of work > there's no point in trying to make the access lock free, as we're > going to be holding the lock anyway. Yes, to both. Thanks David. Coleeen > > Cheers, > David > >> I'm re-testing this version now. >> >> Thanks, >> Coleen >>> >>> thanks, >>> Coleen >>> >>>> >>>> Other than that, this looks good. >>>> >>> >> From Divino.Cesar at microsoft.com Wed Aug 12 02:27:15 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Wed, 12 Aug 2020 02:27:15 +0000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: Message-ID: Gentle ping. Can anyone PTAL? Thanks, Cesar ________________________________ From: hotspot-dev on behalf of Cesar Soares Lucas Sent: August 6, 2020 2:30 PM To: hotspot-dev developers Cc: Brian Stafford ; Aditya Mandaleeka Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Bug: https://bugs.openjdk.java.net/browse/JDK-8244801 Webrev: https://cr.openjdk.java.net/~adityam/cesar/8244801/0/ Need sponsor: Yes Can you please review the above linked patch for the mentioned bug? It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. I tried to structure the code so that the new code and the old printed the same log messages. Please let me know if you want to simplify the method signature and just hard code the log message. I also tried to come up with a short yet descriptive name for the method; let me know if you have suggestions on that as well. Thanks, Cesar Software Engineer - Microsoft From kim.barrett at oracle.com Wed Aug 12 04:00:04 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Aug 2020 00:00:04 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> Message-ID: <0E5C5F78-16D1-402E-9155-E7F7B1A37195@oracle.com> > On Aug 11, 2020, at 5:02 PM, Coleen Phillimore wrote: > > > > On 8/11/20 4:45 PM, Coleen Phillimore wrote: >> >> >> On 8/11/20 1:48 PM, Kim Barrett wrote: >>>> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore wrote: >>>> >>>> >>>> Kim's suggestion for this change looks really good. I'm re-testing this now: >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>> In release_oop_handles, because Service_lock is a "special" lock and >>> touched in lots of places, I'd prefer the deletion not happen under >>> the lock. (I realize this uglifies the code a little bit.) >> >> Because there was no performance reason to use lock free code for this, I add to and clean out the linked list under the Service_lock. I chose a simple implementation because there was no performance or correctness issue to do otherwise. >> >> I'd rather not change this to be ugly unless it's proven to not be correct or performant. > > Scratch that. I see what you mean. Like: > > http://cr.openjdk.java.net/~coleenp/2020/8251336.03.incr/webrev/index.html > > (sorry I had some other questions about making this lock free). > > I'm re-testing this version now. Yes, exactly. That version looks good. From david.holmes at oracle.com Wed Aug 12 04:41:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Aug 2020 14:41:41 +1000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: Message-ID: Hi Cesar, This seems fine to me and I can sponsor it for you once we have a second review. Thanks, David On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > Gentle ping. Can anyone PTAL? > > > Thanks, > Cesar > > ________________________________ > From: hotspot-dev on behalf of Cesar Soares Lucas > Sent: August 6, 2020 2:30 PM > To: hotspot-dev developers > Cc: Brian Stafford ; Aditya Mandaleeka > Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244801 > Webrev: https://cr.openjdk.java.net/~adityam/cesar/8244801/0/ > Need sponsor: Yes > > Can you please review the above linked patch for the mentioned bug? > It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. > > I tried to structure the code so that the new code and the old printed the same > log messages. Please let me know if you want to simplify the method signature > and just hard code the log message. I also tried to come up with a short yet > descriptive name for the method; let me know if you have suggestions on that > as well. > > > Thanks, > Cesar > Software Engineer - Microsoft > From thomas.stuefe at gmail.com Wed Aug 12 06:14:50 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 12 Aug 2020 08:14:50 +0200 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: Message-ID: Man ReservedSpace really should get a revamp. It is a general purpose device, but so polluted with GC/java heap assumptions :( I think this can be done better. Let's look at it: // If OS doesn't support demand paging for large page memory, we need // to use reserve_memory_special() to reserve and pin the entire region. // If there is a backing file directory for this space then whether // large pages are allocated is up to the filesystem of the backing file. // So we ignore the UseLargePages flag in this case. bool special = large && !os::can_commit_large_page_memory(); if (special && _fd_for_heap != -1) { special = false; if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { log_debug(gc, heap)("Ignoring UseLargePages since large page support is up to the file system of the backing file for Java heap"); } } So, IIUC: - Caller requested large pages (since large=true). Note that caller can be anyone, does not have to be the one allocating java heap. - The OS cannot commit large pages on demand (AFAICS only possible on Linux TPH). So we need to explicitly reserve large paged pinned memory, which we call "special" for some reason. - But someone specified fd_for_heap (why "fd_for_heap"? This is a general purpose API. Why so much GC/heap specific code?). So we deny the request and feel this is worth an error message. The error messages conflict: one says basically "we ignore this but the underlying file system may be larged paged, so you still may be good, I don't know". One says "We ignore this, period.". So the problem worth reporting back to the user is that he specified manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is supposed to be a user error. It would be much clearer if that conflict would be handled at argument parsing time, not here. Then this code could just be: bool special = large && !os::can_commit_large_page_memory(); assert(special || _fd_for_heap != -1); That would be cleaner and remove at least some of the "it's used for heap allocations" assumptions from ReservedSpace. We could even rename "fd_for_heap" to a general "fd" and just make it a general argument (so, independent of AllocateHeapAt). Because someone other than java heap might want to reserve memory atop of a file. Just my 5 cent. Sorry for the slight rant. Cheers, Thomas On Wed, Aug 12, 2020 at 6:42 AM David Holmes wrote: > Hi Cesar, > > This seems fine to me and I can sponsor it for you once we have a second > review. > > Thanks, > David > > On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > > Gentle ping. Can anyone PTAL? > > > > > > Thanks, > > Cesar > > > > ________________________________ > > From: hotspot-dev on behalf of > Cesar Soares Lucas > > Sent: August 6, 2020 2:30 PM > > To: hotspot-dev developers > > Cc: Brian Stafford ; Aditya Mandaleeka < > adityam at microsoft.com> > > Subject: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244801 > > Webrev: https://cr.openjdk.java.net/~adityam/cesar/8244801/0/ > > Need sponsor: Yes > > > > Can you please review the above linked patch for the mentioned bug? > > It's a small change that refactor a portion of duplicated code in > `virtualspace.cpp`. > > > > I tried to structure the code so that the new code and the old printed > the same > > log messages. Please let me know if you want to simplify the method > signature > > and just hard code the log message. I also tried to come up with a short > yet > > descriptive name for the method; let me know if you have suggestions on > that > > as well. > > > > > > Thanks, > > Cesar > > Software Engineer - Microsoft > > > From coleen.phillimore at oracle.com Wed Aug 12 11:53:07 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Aug 2020 07:53:07 -0400 Subject: RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997 In-Reply-To: <0E5C5F78-16D1-402E-9155-E7F7B1A37195@oracle.com> References: <9266e676-4952-de71-861d-50b62b5281a4@oracle.com> <9a97d09e-62db-8ed7-083c-df45a3721d0b@oracle.com> <8572709F-DC98-4C96-B2EB-5619C157AE07@oracle.com> <82c1cbfd-a713-eb7b-6d12-c7ae9b182a5c@oracle.com> <3ca5007c-94d3-2cbb-ba81-bde2d2dbaf07@oracle.com> <0E5C5F78-16D1-402E-9155-E7F7B1A37195@oracle.com> Message-ID: On 8/12/20 12:00 AM, Kim Barrett wrote: >> On Aug 11, 2020, at 5:02 PM, Coleen Phillimore wrote: >> >> >> >> On 8/11/20 4:45 PM, Coleen Phillimore wrote: >>> >>> On 8/11/20 1:48 PM, Kim Barrett wrote: >>>>> On Aug 11, 2020, at 10:41 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> Kim's suggestion for this change looks really good. I'm re-testing this now: >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.02/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336 >>>> In release_oop_handles, because Service_lock is a "special" lock and >>>> touched in lots of places, I'd prefer the deletion not happen under >>>> the lock. (I realize this uglifies the code a little bit.) >>> Because there was no performance reason to use lock free code for this, I add to and clean out the linked list under the Service_lock. I chose a simple implementation because there was no performance or correctness issue to do otherwise. >>> >>> I'd rather not change this to be ugly unless it's proven to not be correct or performant. >> Scratch that. I see what you mean. Like: >> >> http://cr.openjdk.java.net/~coleenp/2020/8251336.03.incr/webrev/index.html >> >> (sorry I had some other questions about making this lock free). >> >> I'm re-testing this version now. > Yes, exactly. That version looks good. This version passes all the tests so no surprises.? Thanks Kim! Coleen > From coleen.phillimore at oracle.com Wed Aug 12 15:21:19 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Aug 2020 11:21:19 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code Message-ID: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> Summary: Changed some long declarations to uint64_t/int64_t or unsigned int, depending on context. There are still 'long' declarations left in the code, but they should be changed by developers when working in that code and not as a blanket change.? I didn't change a couple of longs in jfr/leakprofiler, for example.? These are the ones I changed though with some explanation of why: src/hotspot/share/memory/filemap.hpp This can be negative so changed to int64_t. src/hotspot/share/runtime/mutex.cpp The PlatformMutex code takes jlong, which is signed, so that's why I changed these to int64_t. runtime/interfaceSupport.inline.hpp These counters are actually intervals so I changed them to unsigned int. src/hotspot/share/compiler/compileBroker.hpp _peak_compilation_time is signed because it is compared with jlong which is signed. Same with total_compilation_time - elapsedTimer.milliseconds() returns jlong. Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, macosx-x64-debug, linux-aarch64-debug.? Also built on: linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8235765 Thanks, Coleen From lois.foltan at oracle.com Wed Aug 12 16:19:31 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 12 Aug 2020 12:19:31 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> Message-ID: On 8/12/2020 11:21 AM, Coleen Phillimore wrote: > Summary: Changed some long declarations to uint64_t/int64_t or > unsigned int, depending on context. > > There are still 'long' declarations left in the code, but they should > be changed by developers when working in that code and not as a > blanket change.? I didn't change a couple of longs in > jfr/leakprofiler, for example.? These are the ones I changed though > with some explanation of why: > > src/hotspot/share/memory/filemap.hpp > > This can be negative so changed to int64_t. > > src/hotspot/share/runtime/mutex.cpp > > The PlatformMutex code takes jlong, which is signed, so that's why I > changed these to int64_t. > > runtime/interfaceSupport.inline.hpp > > These counters are actually intervals so I changed them to unsigned int. > > src/hotspot/share/compiler/compileBroker.hpp > > _peak_compilation_time is signed because it is compared with jlong > which is signed. > Same with total_compilation_time - elapsedTimer.milliseconds() returns > jlong. > > Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, > macosx-x64-debug, linux-aarch64-debug.? Also built on: > linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8235765 > > Thanks, > Coleen Hi Coleen, Looks good. - runtime/sweeper.hpp ? This is the only file that I wondered why you changed long to int64_t for _total_nof_methods_reclaimed and _total_nof_c2_methods_reclaimed.? Note that the method NMethodSweeper::total_nof_methods_reclaimed returns an int.? Could both of these fields be changed to int instead? Thanks, Lois From coleen.phillimore at oracle.com Wed Aug 12 17:00:58 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Aug 2020 13:00:58 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> Message-ID: <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> On 8/12/20 12:19 PM, Lois Foltan wrote: > On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >> Summary: Changed some long declarations to uint64_t/int64_t or >> unsigned int, depending on context. >> >> There are still 'long' declarations left in the code, but they should >> be changed by developers when working in that code and not as a >> blanket change.? I didn't change a couple of longs in >> jfr/leakprofiler, for example.? These are the ones I changed though >> with some explanation of why: >> >> src/hotspot/share/memory/filemap.hpp >> >> This can be negative so changed to int64_t. >> >> src/hotspot/share/runtime/mutex.cpp >> >> The PlatformMutex code takes jlong, which is signed, so that's why I >> changed these to int64_t. >> >> runtime/interfaceSupport.inline.hpp >> >> These counters are actually intervals so I changed them to unsigned int. >> >> src/hotspot/share/compiler/compileBroker.hpp >> >> _peak_compilation_time is signed because it is compared with jlong >> which is signed. >> Same with total_compilation_time - elapsedTimer.milliseconds() >> returns jlong. >> >> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, >> macosx-x64-debug, linux-aarch64-debug.? Also built on: >> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >> >> Thanks, >> Coleen > > Hi Coleen, > > Looks good. > > - runtime/sweeper.hpp > ? This is the only file that I wondered why you changed long to > int64_t for _total_nof_methods_reclaimed and > _total_nof_c2_methods_reclaimed.? Note that the method > NMethodSweeper::total_nof_methods_reclaimed returns an int.? Could > both of these fields be changed to int instead? Hi Lois, Thank you for looking at this.? Unfortunately, this was an outdated webrev, can you hit reload?? I changed these fields to be uint64_t because they're never signed.? It's likely that the number of methods is never greater than an int, but since it was long to begin with, I kept 64 bit until someone decides an 'int' is better. Since number_of_codecache_sweeps is uint64_t, which seems like a lot too, there could be that many nmethods reclaimed.? I retested with windows just now to be sure. Thanks, Coleen > > Thanks, > Lois From lois.foltan at oracle.com Wed Aug 12 17:20:48 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 12 Aug 2020 13:20:48 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> Message-ID: On 8/12/2020 1:00 PM, Coleen Phillimore wrote: > > > On 8/12/20 12:19 PM, Lois Foltan wrote: >> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>> Summary: Changed some long declarations to uint64_t/int64_t or >>> unsigned int, depending on context. >>> >>> There are still 'long' declarations left in the code, but they >>> should be changed by developers when working in that code and not as >>> a blanket change.? I didn't change a couple of longs in >>> jfr/leakprofiler, for example.? These are the ones I changed though >>> with some explanation of why: >>> >>> src/hotspot/share/memory/filemap.hpp >>> >>> This can be negative so changed to int64_t. >>> >>> src/hotspot/share/runtime/mutex.cpp >>> >>> The PlatformMutex code takes jlong, which is signed, so that's why I >>> changed these to int64_t. >>> >>> runtime/interfaceSupport.inline.hpp >>> >>> These counters are actually intervals so I changed them to unsigned >>> int. >>> >>> src/hotspot/share/compiler/compileBroker.hpp >>> >>> _peak_compilation_time is signed because it is compared with jlong >>> which is signed. >>> Same with total_compilation_time - elapsedTimer.milliseconds() >>> returns jlong. >>> >>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, >>> macosx-x64-debug, linux-aarch64-debug. Also built on: >>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>> >>> Thanks, >>> Coleen >> >> Hi Coleen, >> >> Looks good. >> >> - runtime/sweeper.hpp >> ? This is the only file that I wondered why you changed long to >> int64_t for _total_nof_methods_reclaimed and >> _total_nof_c2_methods_reclaimed.? Note that the method >> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >> both of these fields be changed to int instead? > > Hi Lois, Thank you for looking at this.? Unfortunately, this was an > outdated webrev, can you hit reload?? I changed these fields to be > uint64_t because they're never signed.? It's likely that the number of > methods is never greater than an int, but since it was long to begin > with, I kept 64 bit until someone decides an 'int' is better. Since > number_of_codecache_sweeps is uint64_t, which seems like a lot too, > there could be that many nmethods reclaimed.? I retested with windows > just now to be sure. > > Thanks, > Coleen Yes, that looks better.? Thanks! Lois > > >> >> Thanks, >> Lois > From vladimir.kozlov at oracle.com Wed Aug 12 17:25:27 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Aug 2020 10:25:27 -0700 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> Message-ID: Hi Coleen, I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. What is a story about using int64_t vs jlong? And others *_t vs j* types. Also you need to look on JFR code which collect these data: src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); src/hotspot//share/jfr/metadata/metadata.xml: And I found that metadata.xml have several 'long' uses too: src/hotspot//share/jfr/metadata/metadata.xml: Looking on codecache code and sweeper and I see a lot of inconsistencies in used types :( May be we need an other (compiler) RFE to clean that up. Regards, Vladimir K On 8/12/20 10:00 AM, Coleen Phillimore wrote: > > > On 8/12/20 12:19 PM, Lois Foltan wrote: >> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>> Summary: Changed some long declarations to uint64_t/int64_t or unsigned int, depending on context. >>> >>> There are still 'long' declarations left in the code, but they should be changed by developers when working in that >>> code and not as a blanket change.? I didn't change a couple of longs in jfr/leakprofiler, for example.? These are the >>> ones I changed though with some explanation of why: >>> >>> src/hotspot/share/memory/filemap.hpp >>> >>> This can be negative so changed to int64_t. >>> >>> src/hotspot/share/runtime/mutex.cpp >>> >>> The PlatformMutex code takes jlong, which is signed, so that's why I changed these to int64_t. >>> >>> runtime/interfaceSupport.inline.hpp >>> >>> These counters are actually intervals so I changed them to unsigned int. >>> >>> src/hotspot/share/compiler/compileBroker.hpp >>> >>> _peak_compilation_time is signed because it is compared with jlong which is signed. >>> Same with total_compilation_time - elapsedTimer.milliseconds() returns jlong. >>> >>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, macosx-x64-debug, linux-aarch64-debug.? Also built >>> on: linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>> >>> Thanks, >>> Coleen >> >> Hi Coleen, >> >> Looks good. >> >> - runtime/sweeper.hpp >> ? This is the only file that I wondered why you changed long to int64_t for _total_nof_methods_reclaimed and >> _total_nof_c2_methods_reclaimed.? Note that the method NMethodSweeper::total_nof_methods_reclaimed returns an int. >> Could both of these fields be changed to int instead? > > Hi Lois, Thank you for looking at this.? Unfortunately, this was an outdated webrev, can you hit reload?? I changed > these fields to be uint64_t because they're never signed.? It's likely that the number of methods is never greater than > an int, but since it was long to begin with, I kept 64 bit until someone decides an 'int' is better. Since > number_of_codecache_sweeps is uint64_t, which seems like a lot too, there could be that many nmethods reclaimed.? I > retested with windows just now to be sure. > > Thanks, > Coleen > > >> >> Thanks, >> Lois > From Divino.Cesar at microsoft.com Wed Aug 12 17:41:32 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Wed, 12 Aug 2020 17:41:32 +0000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: , Message-ID: Thanks for reviewing this David and Thomas. Thomas, the error log messages were also confusing to me. I'll refactor the code according to your suggestion and get back to you. ________________________________ From: Thomas St?fe Sent: August 11, 2020 11:14 PM To: David Holmes Cc: Cesar Soares Lucas ; hotspot-dev developers ; Brian Stafford ; Aditya Mandaleeka Subject: Re: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Man ReservedSpace really should get a revamp. It is a general purpose device, but so polluted with GC/java heap assumptions :( I think this can be done better. Let's look at it: // If OS doesn't support demand paging for large page memory, we need // to use reserve_memory_special() to reserve and pin the entire region. // If there is a backing file directory for this space then whether // large pages are allocated is up to the filesystem of the backing file. // So we ignore the UseLargePages flag in this case. bool special = large && !os::can_commit_large_page_memory(); if (special && _fd_for_heap != -1) { special = false; if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { log_debug(gc, heap)("Ignoring UseLargePages since large page support is up to the file system of the backing file for Java heap"); } } So, IIUC: - Caller requested large pages (since large=true). Note that caller can be anyone, does not have to be the one allocating java heap. - The OS cannot commit large pages on demand (AFAICS only possible on Linux TPH). So we need to explicitly reserve large paged pinned memory, which we call "special" for some reason. - But someone specified fd_for_heap (why "fd_for_heap"? This is a general purpose API. Why so much GC/heap specific code?). So we deny the request and feel this is worth an error message. The error messages conflict: one says basically "we ignore this but the underlying file system may be larged paged, so you still may be good, I don't know". One says "We ignore this, period.". So the problem worth reporting back to the user is that he specified manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is supposed to be a user error. It would be much clearer if that conflict would be handled at argument parsing time, not here. Then this code could just be: bool special = large && !os::can_commit_large_page_memory(); assert(special || _fd_for_heap != -1); That would be cleaner and remove at least some of the "it's used for heap allocations" assumptions from ReservedSpace. We could even rename "fd_for_heap" to a general "fd" and just make it a general argument (so, independent of AllocateHeapAt). Because someone other than java heap might want to reserve memory atop of a file. Just my 5 cent. Sorry for the slight rant. Cheers, Thomas On Wed, Aug 12, 2020 at 6:42 AM David Holmes > wrote: Hi Cesar, This seems fine to me and I can sponsor it for you once we have a second review. Thanks, David On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > Gentle ping. Can anyone PTAL? > > > Thanks, > Cesar > > ________________________________ > From: hotspot-dev > on behalf of Cesar Soares Lucas > > Sent: August 6, 2020 2:30 PM > To: hotspot-dev developers > > Cc: Brian Stafford >; Aditya Mandaleeka > > Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244801 > Webrev: https://cr.openjdk.java.net/~adityam/cesar/8244801/0/ > Need sponsor: Yes > > Can you please review the above linked patch for the mentioned bug? > It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. > > I tried to structure the code so that the new code and the old printed the same > log messages. Please let me know if you want to simplify the method signature > and just hard code the log message. I also tried to come up with a short yet > descriptive name for the method; let me know if you have suggestions on that > as well. > > > Thanks, > Cesar > Software Engineer - Microsoft > From coleen.phillimore at oracle.com Wed Aug 12 20:43:26 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Aug 2020 16:43:26 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> Message-ID: <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> Hi Vladimir,? Thank you for looking at this change. On 8/12/20 1:25 PM, Vladimir Kozlov wrote: > Hi Coleen, > > I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. > > What is a story about using int64_t vs jlong? And others *_t vs j* types. jlong is a signed type (either long or long long) so in mutex, even though uint64_t makes more sense, I used int64_t so that they'd be convertible to jlong in the PlatformMutex layer.? I didn't want to pull the string of this sweater even further to convert the jlong to uint64_t in that layer. (If that's even the right thing to do).? We have been trying to avoid using java types like jint, jlong etc, in shared code, but they're pretty much everywhere. > > Also you need to look on JFR code which collect these data: > > src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: > event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); > > src/hotspot//share/jfr/metadata/metadata.xml:??? name="methodReclaimedCount" label="Methods Reclaimed" /> > > And I found that metadata.xml have several 'long' uses too: > > src/hotspot//share/jfr/metadata/metadata.xml:??? contentType="millis" name="peakTimeSpent" label="Peak Time" /> > > Looking on codecache code and sweeper and I see a lot of > inconsistencies in used types :( > May be we need an other (compiler) RFE to clean that up. Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. It's better that 'long' is fixed individually in the sweeper and associated files. The JFR metadata.xml has a lot of "long" types declared in it.? I'm going to revert compileBroker.* too.?? This is going to have to be fixed a little at a time. I'm testing a new more limited version of this change now. Thanks, Coleen > > Regards, > Vladimir K > > On 8/12/20 10:00 AM, Coleen Phillimore wrote: >> >> >> On 8/12/20 12:19 PM, Lois Foltan wrote: >>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>> unsigned int, depending on context. >>>> >>>> There are still 'long' declarations left in the code, but they >>>> should be changed by developers when working in that code and not >>>> as a blanket change.? I didn't change a couple of longs in >>>> jfr/leakprofiler, for example.? These are the ones I changed though >>>> with some explanation of why: >>>> >>>> src/hotspot/share/memory/filemap.hpp >>>> >>>> This can be negative so changed to int64_t. >>>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> >>>> The PlatformMutex code takes jlong, which is signed, so that's why >>>> I changed these to int64_t. >>>> >>>> runtime/interfaceSupport.inline.hpp >>>> >>>> These counters are actually intervals so I changed them to unsigned >>>> int. >>>> >>>> src/hotspot/share/compiler/compileBroker.hpp >>>> >>>> _peak_compilation_time is signed because it is compared with jlong >>>> which is signed. >>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>> returns jlong. >>>> >>>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, >>>> macosx-x64-debug, linux-aarch64-debug. Also built on: >>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>> >>>> Thanks, >>>> Coleen >>> >>> Hi Coleen, >>> >>> Looks good. >>> >>> - runtime/sweeper.hpp >>> ? This is the only file that I wondered why you changed long to >>> int64_t for _total_nof_methods_reclaimed and >>> _total_nof_c2_methods_reclaimed.? Note that the method >>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>> both of these fields be changed to int instead? >> >> Hi Lois, Thank you for looking at this.? Unfortunately, this was an >> outdated webrev, can you hit reload?? I changed these fields to be >> uint64_t because they're never signed.? It's likely that the number >> of methods is never greater than an int, but since it was long to >> begin with, I kept 64 bit until someone decides an 'int' is better. >> Since number_of_codecache_sweeps is uint64_t, which seems like a lot >> too, there could be that many nmethods reclaimed.? I retested with >> windows just now to be sure. >> >> Thanks, >> Coleen >> >> >>> >>> Thanks, >>> Lois >> From lois.foltan at oracle.com Wed Aug 12 21:13:26 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 12 Aug 2020 17:13:26 -0400 Subject: Review Request JDK-8244090: public lookup should find public members of public exported types In-Reply-To: <45df07ad-dd1f-6f20-8cfd-8152f7ce111b@oracle.com> References: <090cff25-2f48-d55f-721d-38acda80029b@oracle.com> <45df07ad-dd1f-6f20-8cfd-8152f7ce111b@oracle.com> Message-ID: <42c1765b-e6a5-5ee0-c543-1030b4636ff4@oracle.com> On 8/11/2020 2:00 PM, Mandy Chung wrote: > It was agreed in an offline discussion with Lois, Kim and John that > this work should wait for the integration of JDK-8247938 and JEP 347 > Enable C++ 14 features. > > This patch is updated to use scoped enum consistent with JDK-8247938. > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.01/index.html Hi Mandy, Still looks good! Thanks, Lois > > Thanks > Mandy > > On 6/18/20 2:12 PM, Mandy Chung wrote: >> Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup >> object on C with PUBLIC access which can be used to look up >> unconditionally exported public types from the module of C. Such >> lookup can only look up this C class defined by loader 1 but not >> another class named "C" defined by loader 2. >> >> JDK-8173978 adds the support for cross-module teleporting. >> publicLookup().in(C.class) was changed to produce a public Lookup >> i.e. with UNCONDITIONAL access.? A public lookup should be able to >> look up public members of any unconditionally exported public types >> including a class named "C" loaded by different loaders.? It reveals >> a bug in VM resolution for Lookup API that adds the loader >> constraints with java.lang.Object as the accessor that constraints a >> public lookup to load one type named C but any more. >> >> The lookup class of a public lookup is irrelevant to the lookup >> context.? Type consistency on P/Q/R live Class objects from the given >> MethodType (MT)is ensured at the following: >> 1. P/Q/R are consistent from the loader of the declaring class of the >> resolved member (D's loader) >> 2. P/Q/R are consistent w.r.t. the invoking class and the caller's MT >> at invocation time (the method handle carries the caller's MT that >> will be verified). >> >> The loader constraints added for public lookup is not necessary and >> adds undesirable constraints.? The proposed fixis to skip adding >> loader constraints if the lookup mode is either TRUSTED or >> UNCONDITIONAL. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.00/index.html >> >> >> Thanks >> Mandy > From coleen.phillimore at oracle.com Wed Aug 12 22:56:44 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Aug 2020 18:56:44 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> Message-ID: <5cb48ccc-a134-992f-ad75-08c75d25b124@oracle.com> On 8/12/20 4:43 PM, Coleen Phillimore wrote: > > Hi Vladimir,? Thank you for looking at this change. > > On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >> Hi Coleen, >> >> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. >> >> What is a story about using int64_t vs jlong? And others *_t vs j* >> types. > > jlong is a signed type (either long or long long) so in mutex, even > though uint64_t makes more sense, I used int64_t so that they'd be > convertible to jlong in the PlatformMutex layer.? I didn't want to > pull the string of this sweater even further to convert the jlong to > uint64_t in that layer. (If that's even the right thing to do).? We > have been trying to avoid using java types like jint, jlong etc, in > shared code, but they're pretty much everywhere. >> >> Also you need to look on JFR code which collect these data: >> >> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >> >> src/hotspot//share/jfr/metadata/metadata.xml:??? > name="methodReclaimedCount" label="Methods Reclaimed" /> >> >> And I found that metadata.xml have several 'long' uses too: >> >> src/hotspot//share/jfr/metadata/metadata.xml:??? > contentType="millis" name="peakTimeSpent" label="Peak Time" /> >> >> Looking on codecache code and sweeper and I see a lot of >> inconsistencies in used types :( >> May be we need an other (compiler) RFE to clean that up. > > Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. It's > better that 'long' is fixed individually in the sweeper and associated > files. > > The JFR metadata.xml has a lot of "long" types declared in it. I'm > going to revert compileBroker.* too.?? This is going to have to be > fixed a little at a time. > > I'm testing a new more limited version of this change now. This is a more limited attempt at stomping out 'long' in the shared code. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.02/webrev thanks, Coleen > > Thanks, > Coleen >> >> Regards, >> Vladimir K >> >> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>> >>> >>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>> unsigned int, depending on context. >>>>> >>>>> There are still 'long' declarations left in the code, but they >>>>> should be changed by developers when working in that code and not >>>>> as a blanket change.? I didn't change a couple of longs in >>>>> jfr/leakprofiler, for example.? These are the ones I changed >>>>> though with some explanation of why: >>>>> >>>>> src/hotspot/share/memory/filemap.hpp >>>>> >>>>> This can be negative so changed to int64_t. >>>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> >>>>> The PlatformMutex code takes jlong, which is signed, so that's why >>>>> I changed these to int64_t. >>>>> >>>>> runtime/interfaceSupport.inline.hpp >>>>> >>>>> These counters are actually intervals so I changed them to >>>>> unsigned int. >>>>> >>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>> >>>>> _peak_compilation_time is signed because it is compared with jlong >>>>> which is signed. >>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>> returns jlong. >>>>> >>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, >>>>> macosx-x64-debug, linux-aarch64-debug. Also built on: >>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> Hi Coleen, >>>> >>>> Looks good. >>>> >>>> - runtime/sweeper.hpp >>>> ? This is the only file that I wondered why you changed long to >>>> int64_t for _total_nof_methods_reclaimed and >>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>>> both of these fields be changed to int instead? >>> >>> Hi Lois, Thank you for looking at this.? Unfortunately, this was an >>> outdated webrev, can you hit reload?? I changed these fields to be >>> uint64_t because they're never signed.? It's likely that the number >>> of methods is never greater than an int, but since it was long to >>> begin with, I kept 64 bit until someone decides an 'int' is better. >>> Since number_of_codecache_sweeps is uint64_t, which seems like a lot >>> too, there could be that many nmethods reclaimed.? I retested with >>> windows just now to be sure. >>> >>> Thanks, >>> Coleen >>> >>> >>>> >>>> Thanks, >>>> Lois >>> > From vladimir.kozlov at oracle.com Wed Aug 12 23:39:30 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Aug 2020 16:39:30 -0700 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <5cb48ccc-a134-992f-ad75-08c75d25b124@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <5cb48ccc-a134-992f-ad75-08c75d25b124@oracle.com> Message-ID: Looks good. I filed compiler's RFE to clean our types: https://bugs.openjdk.java.net/browse/JDK-8251505 Thanks, Vladimir K On 8/12/20 3:56 PM, Coleen Phillimore wrote: > > > On 8/12/20 4:43 PM, Coleen Phillimore wrote: >> >> Hi Vladimir,? Thank you for looking at this change. >> >> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>> Hi Coleen, >>> >>> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. >>> >>> What is a story about using int64_t vs jlong? And others *_t vs j* types. >> >> jlong is a signed type (either long or long long) so in mutex, even though uint64_t makes more sense, I used int64_t >> so that they'd be convertible to jlong in the PlatformMutex layer.? I didn't want to pull the string of this sweater >> even further to convert the jlong to uint64_t in that layer. (If that's even the right thing to do).? We have been >> trying to avoid using java types like jint, jlong etc, in shared code, but they're pretty much everywhere. >>> >>> Also you need to look on JFR code which collect these data: >>> >>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>> >>> src/hotspot//share/jfr/metadata/metadata.xml:??? >>> >>> And I found that metadata.xml have several 'long' uses too: >>> >>> src/hotspot//share/jfr/metadata/metadata.xml:??? >> label="Peak Time" /> >>> >>> Looking on codecache code and sweeper and I see a lot of inconsistencies in used types :( >>> May be we need an other (compiler) RFE to clean that up. >> >> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. It's better that 'long' is fixed individually in the >> sweeper and associated files. >> >> The JFR metadata.xml has a lot of "long" types declared in it. I'm going to revert compileBroker.* too.?? This is >> going to have to be fixed a little at a time. >> >> I'm testing a new more limited version of this change now. > > This is a more limited attempt at stomping out 'long' in the shared code. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.02/webrev > > thanks, > Coleen >> >> Thanks, >> Coleen >>> >>> Regards, >>> Vladimir K >>> >>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>> >>>> >>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>> Summary: Changed some long declarations to uint64_t/int64_t or unsigned int, depending on context. >>>>>> >>>>>> There are still 'long' declarations left in the code, but they should be changed by developers when working in >>>>>> that code and not as a blanket change.? I didn't change a couple of longs in jfr/leakprofiler, for example.? These >>>>>> are the ones I changed though with some explanation of why: >>>>>> >>>>>> src/hotspot/share/memory/filemap.hpp >>>>>> >>>>>> This can be negative so changed to int64_t. >>>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> >>>>>> The PlatformMutex code takes jlong, which is signed, so that's why I changed these to int64_t. >>>>>> >>>>>> runtime/interfaceSupport.inline.hpp >>>>>> >>>>>> These counters are actually intervals so I changed them to unsigned int. >>>>>> >>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>> >>>>>> _peak_compilation_time is signed because it is compared with jlong which is signed. >>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() returns jlong. >>>>>> >>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>> built on: linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> Hi Coleen, >>>>> >>>>> Looks good. >>>>> >>>>> - runtime/sweeper.hpp >>>>> ? This is the only file that I wondered why you changed long to int64_t for _total_nof_methods_reclaimed and >>>>> _total_nof_c2_methods_reclaimed.? Note that the method NMethodSweeper::total_nof_methods_reclaimed returns an int. >>>>> Could both of these fields be changed to int instead? >>>> >>>> Hi Lois, Thank you for looking at this.? Unfortunately, this was an outdated webrev, can you hit reload?? I changed >>>> these fields to be uint64_t because they're never signed.? It's likely that the number of methods is never greater >>>> than an int, but since it was long to begin with, I kept 64 bit until someone decides an 'int' is better. Since >>>> number_of_codecache_sweeps is uint64_t, which seems like a lot too, there could be that many nmethods reclaimed.? I >>>> retested with windows just now to be sure. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>>> >>>>> Thanks, >>>>> Lois >>>> >> > From david.holmes at oracle.com Thu Aug 13 04:07:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Aug 2020 14:07:41 +1000 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> Message-ID: <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> Hi Coleen, And it seemed so simple when you started :) On 13/08/2020 6:43 am, Coleen Phillimore wrote: > > Hi Vladimir,? Thank you for looking at this change. > > On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >> Hi Coleen, >> >> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. "long" is only 32-bit on 64-bit Windows, so if we don't see any issues on Windows then there is a case to be made that all these long fields would appear to be fine if only 32-bit ... that said some of them "obviously" look like they should be size_t as you have made them. >> What is a story about using int64_t vs jlong? And others *_t vs j* types. > > jlong is a signed type (either long or long long) so in mutex, even > though uint64_t makes more sense, I used int64_t so that they'd be > convertible to jlong in the PlatformMutex layer.? I didn't want to pull > the string of this sweater even further to convert the jlong to uint64_t > in that layer. (If that's even the right thing to do).? We have been > trying to avoid using java types like jint, jlong etc, in shared code, > but they're pretty much everywhere. We've been avoiding unnecessary use of j* types in the VM (shared or not) but when the values represent values to/from Java code then the j* types are appropriate. The multiple abstractions Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor make it hard to see exactly how values flow through, and which ones come direct from Java. We should keep the jlong at the Java-connected api level and use uint64_t elsewhere. Separate RFE of course. :) Looking at webrev v02: src/hotspot/share/memory/filemap.hpp You changed the field from long to int64_t but you didn't change the accessor: 87 long filesize() const { return _filesize; } that could give a truncation warning on Windows. That field is set from the stat st_size field, which is defined as type off_t on non-Windows and as ... okay I can't make sense of the win32 docs to figure out whether a plain stat will be a 64-bit or 32-bit [1]. So not clear what the right type is here - but the field and accessor should match. [1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 --- src/hotspot/share/utilities/elfFile.cpp fseek is specified to take a long for the offset, so this change would be a problem on 32-bit builds I think. Thanks, David ----- >> >> Also you need to look on JFR code which collect these data: >> >> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >> >> >> src/hotspot//share/jfr/metadata/metadata.xml:??? > name="methodReclaimedCount" label="Methods Reclaimed" /> >> >> And I found that metadata.xml have several 'long' uses too: >> >> src/hotspot//share/jfr/metadata/metadata.xml:??? > contentType="millis" name="peakTimeSpent" label="Peak Time" /> >> >> Looking on codecache code and sweeper and I see a lot of >> inconsistencies in used types :( >> May be we need an other (compiler) RFE to clean that up. > > Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. It's > better that 'long' is fixed individually in the sweeper and associated > files. > > The JFR metadata.xml has a lot of "long" types declared in it.? I'm > going to revert compileBroker.* too.?? This is going to have to be fixed > a little at a time. > > I'm testing a new more limited version of this change now. > > Thanks, > Coleen >> >> Regards, >> Vladimir K >> >> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>> >>> >>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>> unsigned int, depending on context. >>>>> >>>>> There are still 'long' declarations left in the code, but they >>>>> should be changed by developers when working in that code and not >>>>> as a blanket change.? I didn't change a couple of longs in >>>>> jfr/leakprofiler, for example.? These are the ones I changed though >>>>> with some explanation of why: >>>>> >>>>> src/hotspot/share/memory/filemap.hpp >>>>> >>>>> This can be negative so changed to int64_t. >>>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> >>>>> The PlatformMutex code takes jlong, which is signed, so that's why >>>>> I changed these to int64_t. >>>>> >>>>> runtime/interfaceSupport.inline.hpp >>>>> >>>>> These counters are actually intervals so I changed them to unsigned >>>>> int. >>>>> >>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>> >>>>> _peak_compilation_time is signed because it is compared with jlong >>>>> which is signed. >>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>> returns jlong. >>>>> >>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, windows-x64-debug, >>>>> macosx-x64-debug, linux-aarch64-debug. Also built on: >>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> Hi Coleen, >>>> >>>> Looks good. >>>> >>>> - runtime/sweeper.hpp >>>> ? This is the only file that I wondered why you changed long to >>>> int64_t for _total_nof_methods_reclaimed and >>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>>> both of these fields be changed to int instead? >>> >>> Hi Lois, Thank you for looking at this.? Unfortunately, this was an >>> outdated webrev, can you hit reload?? I changed these fields to be >>> uint64_t because they're never signed.? It's likely that the number >>> of methods is never greater than an int, but since it was long to >>> begin with, I kept 64 bit until someone decides an 'int' is better. >>> Since number_of_codecache_sweeps is uint64_t, which seems like a lot >>> too, there could be that many nmethods reclaimed.? I retested with >>> windows just now to be sure. >>> >>> Thanks, >>> Coleen >>> >>> >>>> >>>> Thanks, >>>> Lois >>> > From adinn at redhat.com Thu Aug 13 08:36:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 Aug 2020 09:36:13 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: Message-ID: On 06/08/2020 16:13, Bernhard Urban-Forster wrote: > can someone sponsor this change please? > > Webrev: http://cr.openjdk.java.net/~burban/8248816/ I have pushed this change. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From coleen.phillimore at oracle.com Thu Aug 13 12:20:47 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Aug 2020 08:20:47 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> Message-ID: <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> On 8/13/20 12:07 AM, David Holmes wrote: > Hi Coleen, > > And it seemed so simple when you started :) Oh gosh no, this sort of change is never simple! > > On 13/08/2020 6:43 am, Coleen Phillimore wrote: >> >> Hi Vladimir,? Thank you for looking at this change. >> >> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>> Hi Coleen, >>> >>> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. > > "long" is only 32-bit on 64-bit Windows, so if we don't see any issues > on Windows then there is a case to be made that all these long fields > would appear to be fine if only 32-bit ... that said some of them > "obviously" look like they should be size_t as you have made them. > >>> What is a story about using int64_t vs jlong? And others *_t vs j* >>> types. >> >> jlong is a signed type (either long or long long) so in mutex, even? >> > though uint64_t makes more sense, I used int64_t so that they'd be >> convertible to jlong in the PlatformMutex layer.? I didn't want to >> pull the string of this sweater even further to convert the jlong to >> uint64_t in that layer. (If that's even the right thing to do).? We >> have been trying to avoid using java types like jint, jlong etc, in >> shared code, but they're pretty much everywhere. > > We've been avoiding unnecessary use of j* types in the VM (shared or > not) but when the values represent values to/from Java code then the > j* types are appropriate. The multiple abstractions > Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor > make it hard to see exactly how values flow through, and which ones > come direct from Java. We should keep the jlong at the Java-connected > api level and use uint64_t elsewhere. Separate RFE of course. :) Yes, another sort of hard-to-impossible to completely fix RFE.? I really think we should just fix individual occurrences as they're found and discourage new uses.? Ideally we should translate all j* types to their appropriate int types once they get passed into the VM implementation code. > > > Looking at webrev v02: > > src/hotspot/share/memory/filemap.hpp > > You changed the field from long to int64_t but you didn't change the > accessor: > > 87?? long?? filesize()? const { return _filesize; } Rats missed one.? I wish the compiler would have complained about this.? Nothing calls this function so I removed it (_filesize is used directly). > > that could give a truncation warning on Windows. That field is set > from the stat st_size field, which is defined as type off_t on > non-Windows and as ... okay I can't make sense of the win32 docs to > figure out whether a plain stat will be a 64-bit or 32-bit [1]. So not > clear what the right type is here - but the field and accessor should > match. > > [1] > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 > > --- > > src/hotspot/share/utilities/elfFile.cpp > > fseek is specified to take a long for the offset, so this change would > be a problem on 32-bit builds I think. These files aren't compiled on windows.? I compiled this on arm32. I think there "long" is 64 bits. #if !defined(_WINDOWS) && !defined(__APPLE__) Thanks, Coleen > > Thanks, > David > ----- > > > >>> >>> Also you need to look on JFR code which collect these data: >>> >>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>> >>> >>> src/hotspot//share/jfr/metadata/metadata.xml:??? >> name="methodReclaimedCount" label="Methods Reclaimed" /> >>> >>> And I found that metadata.xml have several 'long' uses too: >>> >>> src/hotspot//share/jfr/metadata/metadata.xml:??? >> contentType="millis" name="peakTimeSpent" label="Peak Time" /> >>> >>> Looking on codecache code and sweeper and I see a lot of >>> inconsistencies in used types :( >>> May be we need an other (compiler) RFE to clean that up. >> >> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. >> It's better that 'long' is fixed individually in the sweeper and >> associated files. >> >> The JFR metadata.xml has a lot of "long" types declared in it. I'm >> going to revert compileBroker.* too.?? This is going to have to be >> fixed a little at a time. >> >> I'm testing a new more limited version of this change now. >> >> Thanks, >> Coleen >>> >>> Regards, >>> Vladimir K >>> >>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>> >>>> >>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>>> unsigned int, depending on context. >>>>>> >>>>>> There are still 'long' declarations left in the code, but they >>>>>> should be changed by developers when working in that code and not >>>>>> as a blanket change.? I didn't change a couple of longs in >>>>>> jfr/leakprofiler, for example. These are the ones I changed >>>>>> though with some explanation of why: >>>>>> >>>>>> src/hotspot/share/memory/filemap.hpp >>>>>> >>>>>> This can be negative so changed to int64_t. >>>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> >>>>>> The PlatformMutex code takes jlong, which is signed, so that's >>>>>> why I changed these to int64_t. >>>>>> >>>>>> runtime/interfaceSupport.inline.hpp >>>>>> >>>>>> These counters are actually intervals so I changed them to >>>>>> unsigned int. >>>>>> >>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>> >>>>>> _peak_compilation_time is signed because it is compared with >>>>>> jlong which is signed. >>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>>> returns jlong. >>>>>> >>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>> built on: >>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> Hi Coleen, >>>>> >>>>> Looks good. >>>>> >>>>> - runtime/sweeper.hpp >>>>> ? This is the only file that I wondered why you changed long to >>>>> int64_t for _total_nof_methods_reclaimed and >>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>>>> both of these fields be changed to int instead? >>>> >>>> Hi Lois, Thank you for looking at this.? Unfortunately, this was an >>>> outdated webrev, can you hit reload?? I changed these fields to be >>>> uint64_t because they're never signed.? It's likely that the number >>>> of methods is never greater than an int, but since it was long to >>>> begin with, I kept 64 bit until someone decides an 'int' is better. >>>> Since number_of_codecache_sweeps is uint64_t, which seems like a >>>> lot too, there could be that many nmethods reclaimed.? I retested >>>> with windows just now to be sure. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>>> >>>>> Thanks, >>>>> Lois >>>> >> From akozlov at azul.com Thu Aug 13 13:03:53 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 13 Aug 2020 16:03:53 +0300 Subject: Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: References: Message-ID: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Hello Monica, Thank you for your proposal. It was a bit unexpected :) We would be happy to collaborate! Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK community) will need a project or repo for integration. But having win/aarch64 integrated, it may happen that mac/aarch64 support will be just a series of considerably isolated changes. An example is "JDK-8250876: Fix issues with cross-compile on macos" [1]. If all changes will be such self-containing, they may be reviewed and integrated one-by-one. Probably we won't need a project. I think this work is blocked by the JEP for the new platform support. I'll start a discussion email thread for that really soon. I hope we would be able to collaborate in all of the areas. I expect us to get soon to the point when we can start reviewing changes made for win/aarch64 and evaluate how do they fit mac/aarch64. Thanks, Anton [1] https://bugs.openjdk.java.net/browse/JDK-8250876 On 11.08.2020 21:15, Monica Beckwith wrote: > Hello everyone,? > > It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? > > . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? > . Testing (all?regression,?functional, integration?and performance?tests)? > . Integration to?jdk/jdk?(tip)? > > Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? > > If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. > > We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? > > This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? > > Thanks,? > Monica > > [1] http://openjdk.java.net/jeps/8251280 > [2] https://developer.apple.com/programs/universal/ > [3] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > [4] http://openjdk.java.net/projects/#new-project > From akozlov at azul.com Thu Aug 13 14:47:55 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 13 Aug 2020 17:47:55 +0300 Subject: RFC: JEP draft JDK-8251280: macOS/AArch64 Port Message-ID: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> Hello, Could you please look at and comment on a draft of JEP for macOS/AArch64 port[1]? Usually, platform JEPs serve for integration rather than development. According to current understanding, mac/aarch64 is an incremental extension to both mac/x86 and linux-windows/aarch64. It is not expected that a considerable rework will be required to implement mac/aarch64. The JEP initiates a discussion about mac/aarch64 as a supported platform also to enable a certain workflow. If the mac/aarch64 platform would be accepted, changes toward its support will be unblocked for review, testing, and integration. For example, it was possible to isolate build system changes[2] from the rest. Another example would be a solution to the W^X problem, parts of which may be useful for OpenJDK in hardened runtime[3] configuration on mac/x86 (the one which will use MAP_JIT mmap() flag). Gradual changes integration is hoped to reduce overall overhead for reviewers and enable more parties to contribute. I find these goals desirable (at the expense of some overhead for contributors), but the community may have more opinions. I hope that the JEP draft covers all the important topics. If something is missing or wrong, please let me know. Thanks, Anton [1] https://bugs.openjdk.java.net/browse/JDK-8251280 [2] https://bugs.openjdk.java.net/browse/JDK-8250876 [3] https://developer.apple.com/documentation/security/hardened_runtime From david.holmes at oracle.com Fri Aug 14 23:19:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 15 Aug 2020 09:19:54 +1000 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> Message-ID: <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> On 13/08/2020 10:20 pm, Coleen Phillimore wrote: > On 8/13/20 12:07 AM, David Holmes wrote: >> Hi Coleen, >> >> And it seemed so simple when you started :) > > Oh gosh no, this sort of change is never simple! >> >> On 13/08/2020 6:43 am, Coleen Phillimore wrote: >>> >>> Hi Vladimir,? Thank you for looking at this change. >>> >>> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>>> Hi Coleen, >>>> >>>> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. >> >> "long" is only 32-bit on 64-bit Windows, so if we don't see any issues >> on Windows then there is a case to be made that all these long fields >> would appear to be fine if only 32-bit ... that said some of them >> "obviously" look like they should be size_t as you have made them. >> >>>> What is a story about using int64_t vs jlong? And others *_t vs j* >>>> types. >>> >>> jlong is a signed type (either long or long long) so in mutex, even > >>> though uint64_t makes more sense, I used int64_t so that they'd be >>> convertible to jlong in the PlatformMutex layer.? I didn't want to >>> pull the string of this sweater even further to convert the jlong to >>> uint64_t in that layer. (If that's even the right thing to do).? We >>> have been trying to avoid using java types like jint, jlong etc, in >>> shared code, but they're pretty much everywhere. >> >> We've been avoiding unnecessary use of j* types in the VM (shared or >> not) but when the values represent values to/from Java code then the >> j* types are appropriate. The multiple abstractions >> Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor >> make it hard to see exactly how values flow through, and which ones >> come direct from Java. We should keep the jlong at the Java-connected >> api level and use uint64_t elsewhere. Separate RFE of course. :) > > Yes, another sort of hard-to-impossible to completely fix RFE.? I really > think we should just fix individual occurrences as they're found and > discourage new uses.? Ideally we should translate all j* types to their > appropriate int types once they get passed into the VM implementation code. >> >> >> Looking at webrev v02: >> >> src/hotspot/share/memory/filemap.hpp >> >> You changed the field from long to int64_t but you didn't change the >> accessor: >> >> 87?? long?? filesize()? const { return _filesize; } > > Rats missed one.? I wish the compiler would have complained about this. > Nothing calls this function so I removed it (_filesize is used directly). Ok. >> >> that could give a truncation warning on Windows. That field is set >> from the stat st_size field, which is defined as type off_t on >> non-Windows and as ... okay I can't make sense of the win32 docs to >> figure out whether a plain stat will be a 64-bit or 32-bit [1]. So not >> clear what the right type is here - but the field and accessor should >> match. >> >> [1] >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 >> >> >> --- >> >> src/hotspot/share/utilities/elfFile.cpp >> >> fseek is specified to take a long for the offset, so this change would >> be a problem on 32-bit builds I think. > > These files aren't compiled on windows.? I compiled this on arm32. I > think there "long" is 64 bits. No "long" is 32-bit on all 32-bit platforms. So I would expect passing a 64-bit value to a library function expecting a 32-bit argument should generate a compiler warning at best. The fact it doesn't is a concern. I'd be worried about the correctness of this code now. David > #if !defined(_WINDOWS) && !defined(__APPLE__) > > Thanks, > Coleen > >> >> Thanks, >> David >> ----- >> >> >> >>>> >>>> Also you need to look on JFR code which collect these data: >>>> >>>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>>> >>>> >>>> src/hotspot//share/jfr/metadata/metadata.xml:??? >>> name="methodReclaimedCount" label="Methods Reclaimed" /> >>>> >>>> And I found that metadata.xml have several 'long' uses too: >>>> >>>> src/hotspot//share/jfr/metadata/metadata.xml:??? >>> contentType="millis" name="peakTimeSpent" label="Peak Time" /> >>>> >>>> Looking on codecache code and sweeper and I see a lot of >>>> inconsistencies in used types :( >>>> May be we need an other (compiler) RFE to clean that up. >>> >>> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. >>> It's better that 'long' is fixed individually in the sweeper and >>> associated files. >>> >>> The JFR metadata.xml has a lot of "long" types declared in it. I'm >>> going to revert compileBroker.* too.?? This is going to have to be >>> fixed a little at a time. >>> >>> I'm testing a new more limited version of this change now. >>> >>> Thanks, >>> Coleen >>>> >>>> Regards, >>>> Vladimir K >>>> >>>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>>>> unsigned int, depending on context. >>>>>>> >>>>>>> There are still 'long' declarations left in the code, but they >>>>>>> should be changed by developers when working in that code and not >>>>>>> as a blanket change.? I didn't change a couple of longs in >>>>>>> jfr/leakprofiler, for example. These are the ones I changed >>>>>>> though with some explanation of why: >>>>>>> >>>>>>> src/hotspot/share/memory/filemap.hpp >>>>>>> >>>>>>> This can be negative so changed to int64_t. >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> >>>>>>> The PlatformMutex code takes jlong, which is signed, so that's >>>>>>> why I changed these to int64_t. >>>>>>> >>>>>>> runtime/interfaceSupport.inline.hpp >>>>>>> >>>>>>> These counters are actually intervals so I changed them to >>>>>>> unsigned int. >>>>>>> >>>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>>> >>>>>>> _peak_compilation_time is signed because it is compared with >>>>>>> jlong which is signed. >>>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>>>> returns jlong. >>>>>>> >>>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>>> built on: >>>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>>> Hi Coleen, >>>>>> >>>>>> Looks good. >>>>>> >>>>>> - runtime/sweeper.hpp >>>>>> ? This is the only file that I wondered why you changed long to >>>>>> int64_t for _total_nof_methods_reclaimed and >>>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>>>>> both of these fields be changed to int instead? >>>>> >>>>> Hi Lois, Thank you for looking at this.? Unfortunately, this was an >>>>> outdated webrev, can you hit reload?? I changed these fields to be >>>>> uint64_t because they're never signed.? It's likely that the number >>>>> of methods is never greater than an int, but since it was long to >>>>> begin with, I kept 64 bit until someone decides an 'int' is better. >>>>> Since number_of_codecache_sweeps is uint64_t, which seems like a >>>>> lot too, there could be that many nmethods reclaimed.? I retested >>>>> with windows just now to be sure. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>> >>> > From david.holmes at oracle.com Fri Aug 14 23:58:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 15 Aug 2020 09:58:03 +1000 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> Message-ID: <478f8af8-78f8-3ef3-3ba0-e061bbdc39f0@oracle.com> Hi Coleen, I suggest just leaving the elfFile stuff alone. AFAICS the underlying offset is 32-bit on 32-bit and 64-bit on 64-bit and on the platforms we use ElfFile the use of "long" matches that (ILP32 and LP64). This code should probably be using some of the Elf types directly, hidden by a typedef to hide the 32-bit versus 64-bit nomenclature. David On 15/08/2020 9:19 am, David Holmes wrote: > On 13/08/2020 10:20 pm, Coleen Phillimore wrote: >> On 8/13/20 12:07 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> And it seemed so simple when you started :) >> >> Oh gosh no, this sort of change is never simple! >>> >>> On 13/08/2020 6:43 am, Coleen Phillimore wrote: >>>> >>>> Hi Vladimir,? Thank you for looking at this change. >>>> >>>> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>>>> Hi Coleen, >>>>> >>>>> I think it is safe to use 'uint' (uint32_t) for all counts in sweeper. >>> >>> "long" is only 32-bit on 64-bit Windows, so if we don't see any >>> issues on Windows then there is a case to be made that all these long >>> fields would appear to be fine if only 32-bit ... that said some of >>> them "obviously" look like they should be size_t as you have made them. >>> >>>>> What is a story about using int64_t vs jlong? And others *_t vs j* >>>>> types. >>>> >>>> jlong is a signed type (either long or long long) so in mutex, even >>>> > though uint64_t makes more sense, I used int64_t so that they'd be >>>> convertible to jlong in the PlatformMutex layer.? I didn't want to >>>> pull the string of this sweater even further to convert the jlong to >>>> uint64_t in that layer. (If that's even the right thing to do).? We >>>> have been trying to avoid using java types like jint, jlong etc, in >>>> shared code, but they're pretty much everywhere. >>> >>> We've been avoiding unnecessary use of j* types in the VM (shared or >>> not) but when the values represent values to/from Java code then the >>> j* types are appropriate. The multiple abstractions >>> Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor >>> make it hard to see exactly how values flow through, and which ones >>> come direct from Java. We should keep the jlong at the Java-connected >>> api level and use uint64_t elsewhere. Separate RFE of course. :) >> >> Yes, another sort of hard-to-impossible to completely fix RFE.? I >> really think we should just fix individual occurrences as they're >> found and discourage new uses.? Ideally we should translate all j* >> types to their appropriate int types once they get passed into the VM >> implementation code. >>> >>> >>> Looking at webrev v02: >>> >>> src/hotspot/share/memory/filemap.hpp >>> >>> You changed the field from long to int64_t but you didn't change the >>> accessor: >>> >>> 87?? long?? filesize()? const { return _filesize; } >> >> Rats missed one.? I wish the compiler would have complained about >> this. Nothing calls this function so I removed it (_filesize is used >> directly). > > Ok. > >>> >>> that could give a truncation warning on Windows. That field is set >>> from the stat st_size field, which is defined as type off_t on >>> non-Windows and as ... okay I can't make sense of the win32 docs to >>> figure out whether a plain stat will be a 64-bit or 32-bit [1]. So >>> not clear what the right type is here - but the field and accessor >>> should match. >>> >>> [1] >>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 >>> >>> >>> --- >>> >>> src/hotspot/share/utilities/elfFile.cpp >>> >>> fseek is specified to take a long for the offset, so this change >>> would be a problem on 32-bit builds I think. >> >> These files aren't compiled on windows.? I compiled this on arm32. I >> think there "long" is 64 bits. > > No "long" is 32-bit on all 32-bit platforms. So I would expect passing a > 64-bit value to a library function expecting a 32-bit argument should > generate a compiler warning at best. The fact it doesn't is a concern. > I'd be worried about the correctness of this code now. > > David > > >> #if !defined(_WINDOWS) && !defined(__APPLE__) >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>>>> >>>>> Also you need to look on JFR code which collect these data: >>>>> >>>>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>>>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>>>> >>>>> >>>>> src/hotspot//share/jfr/metadata/metadata.xml:??? >>>> name="methodReclaimedCount" label="Methods Reclaimed" /> >>>>> >>>>> And I found that metadata.xml have several 'long' uses too: >>>>> >>>>> src/hotspot//share/jfr/metadata/metadata.xml:??? >>>> contentType="millis" name="peakTimeSpent" label="Peak Time" /> >>>>> >>>>> Looking on codecache code and sweeper and I see a lot of >>>>> inconsistencies in used types :( >>>>> May be we need an other (compiler) RFE to clean that up. >>>> >>>> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. >>>> It's better that 'long' is fixed individually in the sweeper and >>>> associated files. >>>> >>>> The JFR metadata.xml has a lot of "long" types declared in it. I'm >>>> going to revert compileBroker.* too.?? This is going to have to be >>>> fixed a little at a time. >>>> >>>> I'm testing a new more limited version of this change now. >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Regards, >>>>> Vladimir K >>>>> >>>>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>>>>> unsigned int, depending on context. >>>>>>>> >>>>>>>> There are still 'long' declarations left in the code, but they >>>>>>>> should be changed by developers when working in that code and >>>>>>>> not as a blanket change.? I didn't change a couple of longs in >>>>>>>> jfr/leakprofiler, for example. These are the ones I changed >>>>>>>> though with some explanation of why: >>>>>>>> >>>>>>>> src/hotspot/share/memory/filemap.hpp >>>>>>>> >>>>>>>> This can be negative so changed to int64_t. >>>>>>>> >>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>> >>>>>>>> The PlatformMutex code takes jlong, which is signed, so that's >>>>>>>> why I changed these to int64_t. >>>>>>>> >>>>>>>> runtime/interfaceSupport.inline.hpp >>>>>>>> >>>>>>>> These counters are actually intervals so I changed them to >>>>>>>> unsigned int. >>>>>>>> >>>>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>>>> >>>>>>>> _peak_compilation_time is signed because it is compared with >>>>>>>> jlong which is signed. >>>>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>>>>> returns jlong. >>>>>>>> >>>>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>>>> built on: >>>>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>>> Hi Coleen, >>>>>>> >>>>>>> Looks good. >>>>>>> >>>>>>> - runtime/sweeper.hpp >>>>>>> ? This is the only file that I wondered why you changed long to >>>>>>> int64_t for _total_nof_methods_reclaimed and >>>>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. Could >>>>>>> both of these fields be changed to int instead? >>>>>> >>>>>> Hi Lois, Thank you for looking at this.? Unfortunately, this was >>>>>> an outdated webrev, can you hit reload?? I changed these fields to >>>>>> be uint64_t because they're never signed.? It's likely that the >>>>>> number of methods is never greater than an int, but since it was >>>>>> long to begin with, I kept 64 bit until someone decides an 'int' >>>>>> is better. Since number_of_codecache_sweeps is uint64_t, which >>>>>> seems like a lot too, there could be that many nmethods >>>>>> reclaimed.? I retested with windows just now to be sure. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Lois >>>>>> >>>> >> From coleen.phillimore at oracle.com Sat Aug 15 10:59:18 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 15 Aug 2020 06:59:18 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <478f8af8-78f8-3ef3-3ba0-e061bbdc39f0@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> <478f8af8-78f8-3ef3-3ba0-e061bbdc39f0@oracle.com> Message-ID: <3725de19-babb-405c-714c-fc54b426fd02@oracle.com> On 8/14/20 7:58 PM, David Holmes wrote: > Hi Coleen, > > I suggest just leaving the elfFile stuff alone. AFAICS the underlying > offset is 32-bit on 32-bit and 64-bit on 64-bit and on the platforms > we use ElfFile the use of "long" matches that (ILP32 and LP64). This > code should probably be using some of the Elf types directly, hidden > by a typedef to hide the 32-bit versus 64-bit nomenclature. Ok, I reverted elfFile.* also. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.03/webrev Thanks! Coleen > > David > > On 15/08/2020 9:19 am, David Holmes wrote: >> On 13/08/2020 10:20 pm, Coleen Phillimore wrote: >>> On 8/13/20 12:07 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> And it seemed so simple when you started :) >>> >>> Oh gosh no, this sort of change is never simple! >>>> >>>> On 13/08/2020 6:43 am, Coleen Phillimore wrote: >>>>> >>>>> Hi Vladimir,? Thank you for looking at this change. >>>>> >>>>> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> I think it is safe to use 'uint' (uint32_t) for all counts in >>>>>> sweeper. >>>> >>>> "long" is only 32-bit on 64-bit Windows, so if we don't see any >>>> issues on Windows then there is a case to be made that all these >>>> long fields would appear to be fine if only 32-bit ... that said >>>> some of them "obviously" look like they should be size_t as you >>>> have made them. >>>> >>>>>> What is a story about using int64_t vs jlong? And others *_t vs >>>>>> j* types. >>>>> >>>>> jlong is a signed type (either long or long long) so in mutex, >>>>> even > though uint64_t makes more sense, I used int64_t so that >>>>> they'd be >>>>> convertible to jlong in the PlatformMutex layer.? I didn't want to >>>>> pull the string of this sweater even further to convert the jlong >>>>> to uint64_t in that layer. (If that's even the right thing to >>>>> do).? We have been trying to avoid using java types like jint, >>>>> jlong etc, in shared code, but they're pretty much everywhere. >>>> >>>> We've been avoiding unnecessary use of j* types in the VM (shared >>>> or not) but when the values represent values to/from Java code then >>>> the j* types are appropriate. The multiple abstractions >>>> Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor >>>> make it hard to see exactly how values flow through, and which ones >>>> come direct from Java. We should keep the jlong at the >>>> Java-connected api level and use uint64_t elsewhere. Separate RFE >>>> of course. :) >>> >>> Yes, another sort of hard-to-impossible to completely fix RFE.? I >>> really think we should just fix individual occurrences as they're >>> found and discourage new uses.? Ideally we should translate all j* >>> types to their appropriate int types once they get passed into the >>> VM implementation code. >>>> >>>> >>>> Looking at webrev v02: >>>> >>>> src/hotspot/share/memory/filemap.hpp >>>> >>>> You changed the field from long to int64_t but you didn't change >>>> the accessor: >>>> >>>> 87?? long?? filesize()? const { return _filesize; } >>> >>> Rats missed one.? I wish the compiler would have complained about >>> this. Nothing calls this function so I removed it (_filesize is used >>> directly). >> >> Ok. >> >>>> >>>> that could give a truncation warning on Windows. That field is set >>>> from the stat st_size field, which is defined as type off_t on >>>> non-Windows and as ... okay I can't make sense of the win32 docs to >>>> figure out whether a plain stat will be a 64-bit or 32-bit [1]. So >>>> not clear what the right type is here - but the field and accessor >>>> should match. >>>> >>>> [1] >>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 >>>> >>>> >>>> --- >>>> >>>> src/hotspot/share/utilities/elfFile.cpp >>>> >>>> fseek is specified to take a long for the offset, so this change >>>> would be a problem on 32-bit builds I think. >>> >>> These files aren't compiled on windows.? I compiled this on arm32. I >>> think there "long" is 64 bits. >> >> No "long" is 32-bit on all 32-bit platforms. So I would expect >> passing a 64-bit value to a library function expecting a 32-bit >> argument should generate a compiler warning at best. The fact it >> doesn't is a concern. I'd be worried about the correctness of this >> code now. >> >> David >> >> >>> #if !defined(_WINDOWS) && !defined(__APPLE__) >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> >>>>>> >>>>>> Also you need to look on JFR code which collect these data: >>>>>> >>>>>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>>>>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>>>>> >>>>>> >>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>> name="methodReclaimedCount" label="Methods Reclaimed" /> >>>>>> >>>>>> And I found that metadata.xml have several 'long' uses too: >>>>>> >>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>> contentType="millis" name="peakTimeSpent" label="Peak Time" /> >>>>>> >>>>>> Looking on codecache code and sweeper and I see a lot of >>>>>> inconsistencies in used types :( >>>>>> May be we need an other (compiler) RFE to clean that up. >>>>> >>>>> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. >>>>> It's better that 'long' is fixed individually in the sweeper and >>>>> associated files. >>>>> >>>>> The JFR metadata.xml has a lot of "long" types declared in it. I'm >>>>> going to revert compileBroker.* too.?? This is going to have to be >>>>> fixed a little at a time. >>>>> >>>>> I'm testing a new more limited version of this change now. >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> Regards, >>>>>> Vladimir K >>>>>> >>>>>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> >>>>>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>>>>>> unsigned int, depending on context. >>>>>>>>> >>>>>>>>> There are still 'long' declarations left in the code, but they >>>>>>>>> should be changed by developers when working in that code and >>>>>>>>> not as a blanket change.? I didn't change a couple of longs in >>>>>>>>> jfr/leakprofiler, for example. These are the ones I changed >>>>>>>>> though with some explanation of why: >>>>>>>>> >>>>>>>>> src/hotspot/share/memory/filemap.hpp >>>>>>>>> >>>>>>>>> This can be negative so changed to int64_t. >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>> >>>>>>>>> The PlatformMutex code takes jlong, which is signed, so that's >>>>>>>>> why I changed these to int64_t. >>>>>>>>> >>>>>>>>> runtime/interfaceSupport.inline.hpp >>>>>>>>> >>>>>>>>> These counters are actually intervals so I changed them to >>>>>>>>> unsigned int. >>>>>>>>> >>>>>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>>>>> >>>>>>>>> _peak_compilation_time is signed because it is compared with >>>>>>>>> jlong which is signed. >>>>>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>>>>>> returns jlong. >>>>>>>>> >>>>>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>>>>> built on: >>>>>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> Looks good. >>>>>>>> >>>>>>>> - runtime/sweeper.hpp >>>>>>>> ? This is the only file that I wondered why you changed long to >>>>>>>> int64_t for _total_nof_methods_reclaimed and >>>>>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. >>>>>>>> Could both of these fields be changed to int instead? >>>>>>> >>>>>>> Hi Lois, Thank you for looking at this. Unfortunately, this was >>>>>>> an outdated webrev, can you hit reload?? I changed these fields >>>>>>> to be uint64_t because they're never signed.? It's likely that >>>>>>> the number of methods is never greater than an int, but since it >>>>>>> was long to begin with, I kept 64 bit until someone decides an >>>>>>> 'int' is better. Since number_of_codecache_sweeps is uint64_t, >>>>>>> which seems like a lot too, there could be that many nmethods >>>>>>> reclaimed.? I retested with windows just now to be sure. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lois >>>>>>> >>>>> >>> From Divino.Cesar at microsoft.com Sat Aug 15 20:03:35 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Sat, 15 Aug 2020 20:03:35 +0000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: , , Message-ID: Hi David/Thomas, Please see updated webrev here: https://cr.openjdk.java.net/~adityam/cesar/8244801/2/ - I added a validation for `AllocateHeapAt and UseLargePages` in `src/hotspot/share/gc/shared/gcArguments.cpp` because there was some similar validation there. Please advise if this isn't the best place to put such validation. - I renamed `_fd_for_heap` to `_fd` in `virtualspace.*` following your suggestion in the previous e-mail. - Refactored the code in `virtualspace.*` according to the previous e-mail and the changes above. Thanks for looking into this! Cesar? ________________________________ From: hotspot-dev on behalf of Cesar Soares Lucas Sent: August 12, 2020 10:41 AM To: Thomas St?fe ; David Holmes Cc: hotspot-dev developers ; Brian Stafford ; Aditya Mandaleeka Subject: Re: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Thanks for reviewing this David and Thomas. Thomas, the error log messages were also confusing to me. I'll refactor the code according to your suggestion and get back to you. ________________________________ From: Thomas St?fe Sent: August 11, 2020 11:14 PM To: David Holmes Cc: Cesar Soares Lucas ; hotspot-dev developers ; Brian Stafford ; Aditya Mandaleeka Subject: Re: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Man ReservedSpace really should get a revamp. It is a general purpose device, but so polluted with GC/java heap assumptions :( I think this can be done better. Let's look at it: // If OS doesn't support demand paging for large page memory, we need // to use reserve_memory_special() to reserve and pin the entire region. // If there is a backing file directory for this space then whether // large pages are allocated is up to the filesystem of the backing file. // So we ignore the UseLargePages flag in this case. bool special = large && !os::can_commit_large_page_memory(); if (special && _fd_for_heap != -1) { special = false; if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { log_debug(gc, heap)("Ignoring UseLargePages since large page support is up to the file system of the backing file for Java heap"); } } So, IIUC: - Caller requested large pages (since large=true). Note that caller can be anyone, does not have to be the one allocating java heap. - The OS cannot commit large pages on demand (AFAICS only possible on Linux TPH). So we need to explicitly reserve large paged pinned memory, which we call "special" for some reason. - But someone specified fd_for_heap (why "fd_for_heap"? This is a general purpose API. Why so much GC/heap specific code?). So we deny the request and feel this is worth an error message. The error messages conflict: one says basically "we ignore this but the underlying file system may be larged paged, so you still may be good, I don't know". One says "We ignore this, period.". So the problem worth reporting back to the user is that he specified manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is supposed to be a user error. It would be much clearer if that conflict would be handled at argument parsing time, not here. Then this code could just be: bool special = large && !os::can_commit_large_page_memory(); assert(special || _fd_for_heap != -1); That would be cleaner and remove at least some of the "it's used for heap allocations" assumptions from ReservedSpace. We could even rename "fd_for_heap" to a general "fd" and just make it a general argument (so, independent of AllocateHeapAt). Because someone other than java heap might want to reserve memory atop of a file. Just my 5 cent. Sorry for the slight rant. Cheers, Thomas On Wed, Aug 12, 2020 at 6:42 AM David Holmes > wrote: Hi Cesar, This seems fine to me and I can sponsor it for you once we have a second review. Thanks, David On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > Gentle ping. Can anyone PTAL? > > > Thanks, > Cesar > > ________________________________ > From: hotspot-dev > on behalf of Cesar Soares Lucas > > Sent: August 6, 2020 2:30 PM > To: hotspot-dev developers > > Cc: Brian Stafford >; Aditya Mandaleeka > > Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244801&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=Hw08jb5yVYI%2B8FlMzlziE2FVxBKUWe7qBNwOGgRN1%2FU%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F0%2F&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=%2FVhUkQP5FAcGscqqMz3TrllcnRfT1PzMGdgLUAJKX5c%3D&reserved=0 > Need sponsor: Yes > > Can you please review the above linked patch for the mentioned bug? > It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. > > I tried to structure the code so that the new code and the old printed the same > log messages. Please let me know if you want to simplify the method signature > and just hard code the log message. I also tried to come up with a short yet > descriptive name for the method; let me know if you have suggestions on that > as well. > > > Thanks, > Cesar > Software Engineer - Microsoft > From thomas.stuefe at gmail.com Sun Aug 16 09:12:47 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 16 Aug 2020 11:12:47 +0200 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: Message-ID: Hi Cesar, This is going in the right direction, but needs some more thinking. (ccing gc since gc devs may want to look at the argument parsing, see remarks below) --- In my last mail I was kind of rough-sketching my idea, and did not count on you taking it over verbatim, sorry. The assert I quoted had a number of errors: 1) it missed the assert message. Therefore building your patch gets us build errors. For the prototypes of assert, see utilities/debug.hpp. 2) The assert I quoted was wrong since it also fires for special == false && _fd == -1 which is a valid combo. So, after building we now get a crash right away. Allowed combinations: !special && _fd == -1 (anonymous, non-large-paged, this is 99% of standard cases) special && _fd == -1 (anonymous large paged memory) !special && _fd != -1 (mapping over a file) Disallowed: special == true && _fd != -1 (mapping over a file with large pages) So, the assert should be: assert(_fd == -1 || special == false, "wrong arguments") or perhaps clearer to read: --------------- 3) https://cr.openjdk.java.net/~adityam/cesar/8244801/2/src/hotspot/share/gc/shared/gcArguments.cpp.udiff.html Unfortunately argument parsing is more complicated and now raises additional questions. None of those are not the fault of your patch, which only moves logic out of ReservedSpace to arg parsing. + if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { + jio_fprintf(defaultStream::error_stream(), + "AllocateHeapAt and UseLargePages cannot be used together.\n"); + status = false; + } 3.1) You disallow using AllocateHeapAt and UseLargePages at the same time. You use !FLAG_IS_DEFAULT(AllocateHeapAt), similar to code above and below. But I think it is irrelevant whether the user did explicitly specify that flag. If you were to change the default value for AllocateHeapAt to a non-NULL value - for whatever weird reason - it would still be wrong. I think you can just remove the FLAG_IS_DEFAULT and fall back to: - if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { + if (AllocateHeapAt != NULL && UseLargePages) { And I think the same logic applies to AllocateOldGenAt, and affects the other code in this function. 3.2) There is a tiny difference now as to how we treat TPH. Large pages come, at linux, in two flavours: UseHugeTLBFS and UseTransparentHugePages. The former are explicit pinned pages, the latter uses TPH. When UseTransparentHugePages is active, os::can_commit_large_page_memory() returns true (actually, this is the only case on all platforms where this is true). So, the patch causes AllocateHeapAt to be disallowed also for transparent huge pages. Before, that combination would be allowed. Now it's forbidden. But I am not sure whether this combination is in any way relevant, or if it could even work. Especially on persistent memory which was the reason AllocateHeapAt was introduced. Digging into gcArguments.cpp, I believe it is not considered relevant, since at lines 63ff, I find: if (!FLAG_IS_DEFAULT(AllocateOldGenAt)) { ..... // When AllocateOldGenAt is set, we cannot use largepages for entire heap memory. // Only young gen which is allocated in dram can use large pages, but we currently don't support that. FLAG_SET_DEFAULT(UseLargePages, false); <-- } which unconditionally switches off large pages for AllocateOldGenAt. Since AllocateOldGetAt is very similar to AllocateHeapAt, disallowing large pages for AllocateHeapAt - TPH or not - should be also fine. 3.3) which brings me to the next question: should we disallow this flag combination and exit with an error, like your patch does now, or should we quietly disable large pages instead and go on, like lines 63ff does for AllocateOldGenAt? I believe the latter would be better, but I leave this to gc people to answer. ------------------- Finally, a jtreg test may be good, testing the expected behaviour (which kind of depends on the answer to question 3.3). For examples, see the various tests at test/hotspot/jtreg/gc/arguments. ----- Sorry if this balloons a bit. I think this cleanup is very worthwhile. Cheers, Thomas On Sat, Aug 15, 2020 at 10:03 PM Cesar Soares Lucas < Divino.Cesar at microsoft.com> wrote: > Hi David/Thomas, > > Please see updated webrev here: > https://cr.openjdk.java.net/~adityam/cesar/8244801/2/ > > - I added a validation for `AllocateHeapAt and UseLargePages` in > `src/hotspot/share/gc/shared/gcArguments.cpp` because there was some > similar > validation there. Please advise if this isn't the best place to put such > validation. > > - I renamed `_fd_for_heap` to `_fd` in `virtualspace.*` following your > suggestion > in the previous e-mail. > > - Refactored the code in `virtualspace.*` according to the previous e-mail > and the > changes above. > > > Thanks for looking into this! > Cesar? > > ------------------------------ > *From:* hotspot-dev on behalf of > Cesar Soares Lucas > *Sent:* August 12, 2020 10:41 AM > *To:* Thomas St?fe ; David Holmes < > david.holmes at oracle.com> > *Cc:* hotspot-dev developers ; Brian > Stafford ; Aditya Mandaleeka < > adityam at microsoft.com> > *Subject:* Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > Thanks for reviewing this David and Thomas. > > Thomas, the error log messages were also confusing to me. I'll refactor > the code according to your suggestion and get back to you. > > > ________________________________ > From: Thomas St?fe > Sent: August 11, 2020 11:14 PM > To: David Holmes > Cc: Cesar Soares Lucas ; hotspot-dev > developers ; Brian Stafford < > Brian.Stafford at microsoft.com>; Aditya Mandaleeka > Subject: Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > Man ReservedSpace really should get a revamp. It is a general purpose > device, but so polluted with GC/java heap assumptions :( > > I think this can be done better. Let's look at it: > > // If OS doesn't support demand paging for large page memory, we need > // to use reserve_memory_special() to reserve and pin the entire region. > // If there is a backing file directory for this space then whether > // large pages are allocated is up to the filesystem of the backing > file. > // So we ignore the UseLargePages flag in this case. > bool special = large && !os::can_commit_large_page_memory(); > if (special && _fd_for_heap != -1) { > special = false; > if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || > !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { > log_debug(gc, heap)("Ignoring UseLargePages since large page > support is up to the file system of the backing file for Java heap"); > } > } > > So, IIUC: > > - Caller requested large pages (since large=true). Note that caller can be > anyone, does not have to be the one allocating java heap. > - The OS cannot commit large pages on demand (AFAICS only possible on > Linux TPH). So we need to explicitly reserve large paged pinned memory, > which we call "special" for some reason. > - But someone specified fd_for_heap (why "fd_for_heap"? This is a general > purpose API. Why so much GC/heap specific code?). So we deny the request > and feel this is worth an error message. > > The error messages conflict: one says basically "we ignore this but the > underlying file system may be larged paged, so you still may be good, I > don't know". One says "We ignore this, period.". > > So the problem worth reporting back to the user is that he specified > manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is > supposed to be a user error. It would be much clearer if that conflict > would be handled at argument parsing time, not here. Then this code could > just be: > > bool special = large && !os::can_commit_large_page_memory(); > assert(special || _fd_for_heap != -1); > > That would be cleaner and remove at least some of the "it's used for heap > allocations" assumptions from ReservedSpace. We could even rename > "fd_for_heap" to a general "fd" and just make it a general argument (so, > independent of AllocateHeapAt). Because someone other than java heap might > want to reserve memory atop of a file. > > Just my 5 cent. Sorry for the slight rant. > > Cheers, Thomas > > > > On Wed, Aug 12, 2020 at 6:42 AM David Holmes > wrote: > Hi Cesar, > > This seems fine to me and I can sponsor it for you once we have a second > review. > > Thanks, > David > > On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > > Gentle ping. Can anyone PTAL? > > > > > > Thanks, > > Cesar > > > > ________________________________ > > From: hotspot-dev hotspot-dev-retn at openjdk.java.net>> on behalf of Cesar Soares Lucas < > Divino.Cesar at microsoft.com> > > Sent: August 6, 2020 2:30 PM > > To: hotspot-dev developers hotspot-dev at openjdk.java.net>> > > Cc: Brian Stafford Brian.Stafford at microsoft.com>>; Aditya Mandaleeka > > > Subject: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > > > > Bug: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244801&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=Hw08jb5yVYI%2B8FlMzlziE2FVxBKUWe7qBNwOGgRN1%2FU%3D&reserved=0 > > > > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F0%2F&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=%2FVhUkQP5FAcGscqqMz3TrllcnRfT1PzMGdgLUAJKX5c%3D&reserved=0 > > > > Need sponsor: Yes > > > > Can you please review the above linked patch for the mentioned bug? > > It's a small change that refactor a portion of duplicated code in > `virtualspace.cpp`. > > > > I tried to structure the code so that the new code and the old printed > the same > > log messages. Please let me know if you want to simplify the method > signature > > and just hard code the log message. I also tried to come up with a short > yet > > descriptive name for the method; let me know if you have suggestions on > that > > as well. > > > > > > Thanks, > > Cesar > > Software Engineer - Microsoft > > > From david.holmes at oracle.com Mon Aug 17 01:54:15 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Aug 2020 11:54:15 +1000 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <3725de19-babb-405c-714c-fc54b426fd02@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> <478f8af8-78f8-3ef3-3ba0-e061bbdc39f0@oracle.com> <3725de19-babb-405c-714c-fc54b426fd02@oracle.com> Message-ID: <0ba60343-bf4d-fdef-ab13-cae04f9bf6ff@oracle.com> Looks good. Thanks, David On 15/08/2020 8:59 pm, Coleen Phillimore wrote: > > > On 8/14/20 7:58 PM, David Holmes wrote: >> Hi Coleen, >> >> I suggest just leaving the elfFile stuff alone. AFAICS the underlying >> offset is 32-bit on 32-bit and 64-bit on 64-bit and on the platforms >> we use ElfFile the use of "long" matches that (ILP32 and LP64). This >> code should probably be using some of the Elf types directly, hidden >> by a typedef to hide the 32-bit versus 64-bit nomenclature. > > Ok, I reverted elfFile.* also. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8235765.03/webrev > > Thanks! > Coleen >> >> David >> >> On 15/08/2020 9:19 am, David Holmes wrote: >>> On 13/08/2020 10:20 pm, Coleen Phillimore wrote: >>>> On 8/13/20 12:07 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> And it seemed so simple when you started :) >>>> >>>> Oh gosh no, this sort of change is never simple! >>>>> >>>>> On 13/08/2020 6:43 am, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Vladimir,? Thank you for looking at this change. >>>>>> >>>>>> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> I think it is safe to use 'uint' (uint32_t) for all counts in >>>>>>> sweeper. >>>>> >>>>> "long" is only 32-bit on 64-bit Windows, so if we don't see any >>>>> issues on Windows then there is a case to be made that all these >>>>> long fields would appear to be fine if only 32-bit ... that said >>>>> some of them "obviously" look like they should be size_t as you >>>>> have made them. >>>>> >>>>>>> What is a story about using int64_t vs jlong? And others *_t vs >>>>>>> j* types. >>>>>> >>>>>> jlong is a signed type (either long or long long) so in mutex, >>>>>> even > though uint64_t makes more sense, I used int64_t so that >>>>>> they'd be >>>>>> convertible to jlong in the PlatformMutex layer.? I didn't want to >>>>>> pull the string of this sweater even further to convert the jlong >>>>>> to uint64_t in that layer. (If that's even the right thing to >>>>>> do).? We have been trying to avoid using java types like jint, >>>>>> jlong etc, in shared code, but they're pretty much everywhere. >>>>> >>>>> We've been avoiding unnecessary use of j* types in the VM (shared >>>>> or not) but when the values represent values to/from Java code then >>>>> the j* types are appropriate. The multiple abstractions >>>>> Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor >>>>> make it hard to see exactly how values flow through, and which ones >>>>> come direct from Java. We should keep the jlong at the >>>>> Java-connected api level and use uint64_t elsewhere. Separate RFE >>>>> of course. :) >>>> >>>> Yes, another sort of hard-to-impossible to completely fix RFE.? I >>>> really think we should just fix individual occurrences as they're >>>> found and discourage new uses.? Ideally we should translate all j* >>>> types to their appropriate int types once they get passed into the >>>> VM implementation code. >>>>> >>>>> >>>>> Looking at webrev v02: >>>>> >>>>> src/hotspot/share/memory/filemap.hpp >>>>> >>>>> You changed the field from long to int64_t but you didn't change >>>>> the accessor: >>>>> >>>>> 87?? long?? filesize()? const { return _filesize; } >>>> >>>> Rats missed one.? I wish the compiler would have complained about >>>> this. Nothing calls this function so I removed it (_filesize is used >>>> directly). >>> >>> Ok. >>> >>>>> >>>>> that could give a truncation warning on Windows. That field is set >>>>> from the stat st_size field, which is defined as type off_t on >>>>> non-Windows and as ... okay I can't make sense of the win32 docs to >>>>> figure out whether a plain stat will be a 64-bit or 32-bit [1]. So >>>>> not clear what the right type is here - but the field and accessor >>>>> should match. >>>>> >>>>> [1] >>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 >>>>> >>>>> >>>>> --- >>>>> >>>>> src/hotspot/share/utilities/elfFile.cpp >>>>> >>>>> fseek is specified to take a long for the offset, so this change >>>>> would be a problem on 32-bit builds I think. >>>> >>>> These files aren't compiled on windows.? I compiled this on arm32. I >>>> think there "long" is 64 bits. >>> >>> No "long" is 32-bit on all 32-bit platforms. So I would expect >>> passing a 64-bit value to a library function expecting a 32-bit >>> argument should generate a compiler warning at best. The fact it >>> doesn't is a concern. I'd be worried about the correctness of this >>> code now. >>> >>> David >>> >>> >>>> #if !defined(_WINDOWS) && !defined(__APPLE__) >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>>> >>>>>>> Also you need to look on JFR code which collect these data: >>>>>>> >>>>>>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>>>>>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>>>>>> >>>>>>> >>>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>>> name="methodReclaimedCount" label="Methods Reclaimed" /> >>>>>>> >>>>>>> And I found that metadata.xml have several 'long' uses too: >>>>>>> >>>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>>> contentType="millis" name="peakTimeSpent" label="Peak Time" /> >>>>>>> >>>>>>> Looking on codecache code and sweeper and I see a lot of >>>>>>> inconsistencies in used types :( >>>>>>> May be we need an other (compiler) RFE to clean that up. >>>>>> >>>>>> Yes, I agree. I'm going to revert sweeper, nmethod and vmStructs. >>>>>> It's better that 'long' is fixed individually in the sweeper and >>>>>> associated files. >>>>>> >>>>>> The JFR metadata.xml has a lot of "long" types declared in it. I'm >>>>>> going to revert compileBroker.* too.?? This is going to have to be >>>>>> fixed a little at a time. >>>>>> >>>>>> I'm testing a new more limited version of this change now. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>>> >>>>>>> Regards, >>>>>>> Vladimir K >>>>>>> >>>>>>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>>>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>>>>>> Summary: Changed some long declarations to uint64_t/int64_t or >>>>>>>>>> unsigned int, depending on context. >>>>>>>>>> >>>>>>>>>> There are still 'long' declarations left in the code, but they >>>>>>>>>> should be changed by developers when working in that code and >>>>>>>>>> not as a blanket change.? I didn't change a couple of longs in >>>>>>>>>> jfr/leakprofiler, for example. These are the ones I changed >>>>>>>>>> though with some explanation of why: >>>>>>>>>> >>>>>>>>>> src/hotspot/share/memory/filemap.hpp >>>>>>>>>> >>>>>>>>>> This can be negative so changed to int64_t. >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>> >>>>>>>>>> The PlatformMutex code takes jlong, which is signed, so that's >>>>>>>>>> why I changed these to int64_t. >>>>>>>>>> >>>>>>>>>> runtime/interfaceSupport.inline.hpp >>>>>>>>>> >>>>>>>>>> These counters are actually intervals so I changed them to >>>>>>>>>> unsigned int. >>>>>>>>>> >>>>>>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>>>>>> >>>>>>>>>> _peak_compilation_time is signed because it is compared with >>>>>>>>>> jlong which is signed. >>>>>>>>>> Same with total_compilation_time - elapsedTimer.milliseconds() >>>>>>>>>> returns jlong. >>>>>>>>>> >>>>>>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. Also >>>>>>>>>> built on: >>>>>>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>>>>>> >>>>>>>>>> open webrev at >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> - runtime/sweeper.hpp >>>>>>>>> ? This is the only file that I wondered why you changed long to >>>>>>>>> int64_t for _total_nof_methods_reclaimed and >>>>>>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>>>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. >>>>>>>>> Could both of these fields be changed to int instead? >>>>>>>> >>>>>>>> Hi Lois, Thank you for looking at this. Unfortunately, this was >>>>>>>> an outdated webrev, can you hit reload?? I changed these fields >>>>>>>> to be uint64_t because they're never signed.? It's likely that >>>>>>>> the number of methods is never greater than an int, but since it >>>>>>>> was long to begin with, I kept 64 bit until someone decides an >>>>>>>> 'int' is better. Since number_of_codecache_sweeps is uint64_t, >>>>>>>> which seems like a lot too, there could be that many nmethods >>>>>>>> reclaimed.? I retested with windows just now to be sure. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lois >>>>>>>> >>>>>> >>>> > From david.holmes at oracle.com Mon Aug 17 02:07:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Aug 2020 12:07:59 +1000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: References: Message-ID: <7a0f37fb-74e3-11d5-8b01-8ead174e13b5@oracle.com> Cesar, Thomas, As this is no longer a simple code refactoring I'm withdrawing from the review process. I'm also about to go on a weeks vacation. Cheers, David On 16/08/2020 7:12 pm, Thomas St?fe wrote: > Hi Cesar, > > This is going in the right direction, but needs some more thinking. > > (ccing gc since gc devs may want to look at the argument parsing, see > remarks below) > > --- > > In my last mail I was kind of rough-sketching my idea, and did not count > on you taking it over verbatim, sorry. The assert I quoted had a number > of errors: > > 1) it missed the assert message. Therefore building your patch gets us > build errors. For the prototypes of assert, see utilities/debug.hpp. > > 2) The assert I quoted was wrong since it also fires for special == > false && _fd == -1 which is a valid?combo. So, after building we now get > a crash right away. > > Allowed combinations: > > !special && _fd == -1 (anonymous, non-large-paged, this is 99% of > standard cases) > special && _fd == -1 ?(anonymous large paged memory) > !special && _fd != -1? (mapping over a file) > > Disallowed: > special == true && _fd != -1 ?(mapping over a file with large pages) > > So, the assert should be: > > assert(_fd == -1 || special == false, "wrong arguments") > > or perhaps?clearer to read: > > --------------- > > 3) > https://cr.openjdk.java.net/~adityam/cesar/8244801/2/src/hotspot/share/gc/shared/gcArguments.cpp.udiff.html > > Unfortunately argument parsing is more complicated and now raises > additional questions. None of those are not the fault of your patch, > which only moves logic out of ReservedSpace to arg parsing. > > + ? if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { > + ? ? jio_fprintf(defaultStream::error_stream(), > + ? ? ? "AllocateHeapAt and UseLargePages cannot be used together.\n"); > + ? ? status = false; > + ? } > > 3.1) You disallow using AllocateHeapAt and UseLargePages at the same > time. You use !FLAG_IS_DEFAULT(AllocateHeapAt), similar to code above > and below. But I think it is irrelevant whether the user did explicitly > specify that flag. If you were to change the default value for > AllocateHeapAt to a non-NULL value - for whatever weird reason - it > would still be wrong. > > I think you can just remove the FLAG_IS_DEFAULT and fall back to: > > - if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { > + if (AllocateHeapAt != NULL && UseLargePages) { > > And I think the same logic applies to AllocateOldGenAt, and affects the > other code in this function. > > 3.2) There is a tiny difference now as to how we treat TPH. > > Large pages come, at linux, in two flavours: UseHugeTLBFS and > UseTransparentHugePages. The former are explicit pinned pages, the > latter uses TPH. When UseTransparentHugePages is active, > os::can_commit_large_page_memory() returns true (actually, this is the > only case on all platforms where this is true). > > So, the patch causes AllocateHeapAt to be disallowed also for > transparent huge pages. Before, that combination would be allowed. Now > it's forbidden. > > But I am not sure whether this combination is in any way relevant, or if > it could even work. Especially on persistent?memory which was the reason > AllocateHeapAt was introduced. Digging into gcArguments.cpp, I believe > it is not considered relevant, since at lines 63ff, I find: > > ? if (!FLAG_IS_DEFAULT(AllocateOldGenAt)) { > ?..... > ? ? // When AllocateOldGenAt is set, we cannot use largepages for > entire heap memory. > ? ? // Only young gen which is allocated in dram can use large pages, > but we currently don't support that. > ? ? FLAG_SET_DEFAULT(UseLargePages, false);? <-- > ? } > > which unconditionally switches off large pages for AllocateOldGenAt. > Since AllocateOldGetAt is very similar to AllocateHeapAt, disallowing > large pages for AllocateHeapAt - TPH or not - should be also fine. > > 3.3) which brings me to the next question: should we disallow this flag > combination and exit with an error, like your patch does now, or should > we quietly disable large pages instead and go on, like lines 63ff does > for AllocateOldGenAt? > > I believe the latter would be better, but I leave this to gc people to > answer. > > ------------------- > > Finally, a jtreg test may be good, testing the expected behaviour (which > kind of depends on the answer to question 3.3). For examples, see the > various tests at test/hotspot/jtreg/gc/arguments. > > ----- > > Sorry if this balloons a bit.?I think this cleanup is very worthwhile. > > Cheers, Thomas > > > > > > > > On Sat, Aug 15, 2020 at 10:03 PM Cesar Soares Lucas > > wrote: > > Hi David/Thomas, > > Please see updated webrev here: > https://cr.openjdk.java.net/~adityam/cesar/8244801/2/ > > - I added a validation for `AllocateHeapAt and UseLargePages` in > ? `src/hotspot/share/gc/shared/gcArguments.cpp` because there was > some similar > ? validation there. Please advise if this isn't the best place to > put such validation. > > - I renamed `_fd_for_heap` to `_fd` in `virtualspace.*` following > your suggestion > ? in the previous e-mail. > > - Refactored the code in `virtualspace.*` according to the previous > e-mail and the > ? changes above. > > > Thanks for looking into this! > Cesar? > > ------------------------------------------------------------------------ > *From:* hotspot-dev > on behalf of Cesar > Soares Lucas > > *Sent:* August 12, 2020 10:41 AM > *To:* Thomas St?fe >; David Holmes > > > *Cc:* hotspot-dev developers >; Brian Stafford > >; Aditya Mandaleeka > > > *Subject:* Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > Thanks for reviewing this David and Thomas. > > Thomas, the error log messages were also confusing to me. I'll > refactor the code according to your suggestion and get back to you. > > > ________________________________ > From: Thomas St?fe > > Sent: August 11, 2020 11:14 PM > To: David Holmes > > Cc: Cesar Soares Lucas >; hotspot-dev developers > >; Brian Stafford > >; Aditya Mandaleeka > > > Subject: Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > Man ReservedSpace really should get a revamp. It is a general > purpose device, but so polluted with GC/java heap assumptions :( > > I think this can be done better. Let's look at it: > > ?? // If OS doesn't support demand paging for large page memory, we > need > ?? // to use reserve_memory_special() to reserve and pin the entire > region. > ?? // If there is a backing file directory for this space then whether > ?? // large pages are allocated is up to the filesystem of the > backing file. > ?? // So we ignore the UseLargePages flag in this case. > ?? bool special = large && !os::can_commit_large_page_memory(); > ?? if (special && _fd_for_heap != -1) { > ???? special = false; > ???? if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || > ?????? !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { > ?????? log_debug(gc, heap)("Ignoring UseLargePages since large page > support is up to the file system of the backing file for Java heap"); > ???? } > ?? } > > So, IIUC: > > - Caller requested large pages (since large=true). Note that caller > can be anyone, does not have to be the one allocating java heap. > - The OS cannot commit large pages on demand (AFAICS only possible > on Linux TPH). So we need to explicitly reserve large paged pinned > memory, which we call "special" for some reason. > - But someone specified fd_for_heap (why "fd_for_heap"? This is a > general purpose API. Why so much GC/heap specific code?). So we deny > the request and feel this is worth an error message. > > The error messages conflict: one says basically "we ignore this but > the underlying file system may be larged paged, so you still may be > good, I don't know". One says "We ignore this, period.". > > So the problem worth reporting back to the user is that he specified > manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is > supposed to be a user error. It would be much clearer if that > conflict would be handled at argument parsing time, not here. Then > this code could just be: > > bool special = large && !os::can_commit_large_page_memory(); > assert(special || _fd_for_heap != -1); > > That would be cleaner and remove at least some of the "it's used for > heap allocations" assumptions from ReservedSpace. We could even > rename "fd_for_heap" to a general "fd" and just make it a general > argument (so, independent of AllocateHeapAt). Because someone other > than java heap might want to reserve memory atop of a file. > > Just my 5 cent. Sorry for the slight rant. > > Cheers, Thomas > > > > On Wed, Aug 12, 2020 at 6:42 AM David Holmes > >> wrote: > Hi Cesar, > > This seems fine to me and I can sponsor it for you once we have a second > review. > > Thanks, > David > > On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > > Gentle ping. Can anyone PTAL? > > > > > > Thanks, > > Cesar > > > > ________________________________ > > From: hotspot-dev >> on behalf of Cesar > Soares Lucas >> > > Sent: August 6, 2020 2:30 PM > > To: hotspot-dev developers >> > > Cc: Brian Stafford >>; Aditya Mandaleeka > >> > > Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > > > > Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244801&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=Hw08jb5yVYI%2B8FlMzlziE2FVxBKUWe7qBNwOGgRN1%2FU%3D&reserved=0 > > > Webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F0%2F&data=02%7C01%7Cdivino.cesar%40microsoft.com%7C0c4400b1693449eecd1008d83ee98678%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637328519987544935&sdata=%2FVhUkQP5FAcGscqqMz3TrllcnRfT1PzMGdgLUAJKX5c%3D&reserved=0 > > > Need sponsor: Yes > > > > Can you please review the above linked patch for the mentioned bug? > > It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. > > > > I tried to structure the code so that the new code and the old printed the same > > log messages. Please let me know if you want to simplify the method signature > > and just hard code the log message. I also tried to come up with a short yet > > descriptive name for the method; let me know if you have suggestions on that > > as well. > > > > > > Thanks, > > Cesar > > Software Engineer - Microsoft > > > From kim.barrett at oracle.com Mon Aug 17 10:32:19 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 17 Aug 2020 06:32:19 -0400 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc Message-ID: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> Please review this followup to JDK-8247976 [1], rehoming the information from two subpages of the wiki Style Guide to jdk/jdk/doc. The "Naming HotSpot JTReg Tests" wiki page has been summarized as an additional small section in the HotSpot Style Guide. The "Native/Unit Test Development Guidelines" has been transferred wholesale to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was accomplished by cut-and-paste of the wiki page content to the new file, then adding markdown annotations corresponding to the wiki page's formatting. No significant modifications were made to the text, not even to correct typos and other errors that seem obvious. I want to get the file in place before doing any updates to the content. [1] https://bugs.openjdk.java.net/browse/JDK-8247976 I think this change doesn't modify the Style Guide in any substantive way, so I think a simple review is sufficient, rather than needing to gather consensus for the change from the Group Members. Once this change is pushed I'll update the wiki pages to note they are obsolete and provide a forwarding pointer. CR: https://bugs.openjdk.java.net/browse/JDK-8251888 Webrev: https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ From aph at redhat.com Mon Aug 17 12:28:50 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Aug 2020 13:28:50 +0100 Subject: RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> Message-ID: <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> On 13/08/2020 15:47, Anton Kozlov wrote: > Another example would be a solution to the W^X problem, parts of > which may be useful for OpenJDK in hardened runtime[3] configuration > on mac/x86 (the one which will use MAP_JIT mmap() flag). The JEP looks good to me. Re W^X: there are very few places where we now need runtime-patchable methods in the code cache. On AArch64, we deoptimize and recompile rather than patch in most cases. This is because the only instructions we're allowed to patch concurrently are direct jumps, traps, and nops. This leads to very little slowdown in practice because in a tiered- compilation-enabled JVM 90% of recompilations are due to tier escalation rather than patching needed, and most fields are resolved in the interpreter before C1 kicks in. The remaining places we patch today are nmethod::make_not_entrant_or_zombie and compiled inline caches for method calls. We can perhaps get rid of the first because we now have nmethod entry barriers, and Erik ?sterlund has been working on a replacement for inline caches. Finally, we would have to change the trampoline logic to go via a separate data table. I think that's it. Not that I'm suggesting you need this for Apple/ AArch64, but we're very close. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Mon Aug 17 13:17:47 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 17 Aug 2020 15:17:47 +0200 Subject: RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> Message-ID: <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> Hi, On 2020-08-17 14:28, Andrew Haley wrote: > On 13/08/2020 15:47, Anton Kozlov wrote: > >> Another example would be a solution to the W^X problem, parts of >> which may be useful for OpenJDK in hardened runtime[3] configuration >> on mac/x86 (the one which will use MAP_JIT mmap() flag). > The JEP looks good to me. > > Re W^X: there are very few places where we now need runtime-patchable > methods in the code cache. > > On AArch64, we deoptimize and recompile rather than patch in most > cases. This is because the only instructions we're allowed to patch > concurrently are direct jumps, traps, and nops. > > This leads to very little slowdown in practice because in a tiered- > compilation-enabled JVM 90% of recompilations are due to tier > escalation rather than patching needed, and most fields are resolved > in the interpreter before C1 kicks in. > > The remaining places we patch today are > nmethod::make_not_entrant_or_zombie and compiled inline caches for > method calls. We can perhaps get rid of the first because we now have > nmethod entry barriers, and Erik ?sterlund has been working on a > replacement for inline caches. Right. The relevant JEP draft for these changes is here for interested readers: https://bugs.openjdk.java.net/browse/JDK-8221828 In my current implementation prototype, all the above code patching has indeed been removed. I still have the nmethod entry barriers, but as mentioned they do not patch anything on AArch64. Thanks, /Erik > Finally, we would have to change the trampoline logic to go via a > separate data table. > > I think that's it. Not that I'm suggesting you need this for Apple/ > AArch64, but we're very close. > From coleen.phillimore at oracle.com Mon Aug 17 14:06:54 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Aug 2020 10:06:54 -0400 Subject: RFR (S) 8235765: Use of the long type should be avoided in shared code In-Reply-To: <0ba60343-bf4d-fdef-ab13-cae04f9bf6ff@oracle.com> References: <74c209d7-0dd5-c608-abca-cb7c2aaeb8cd@oracle.com> <580ba05c-0379-b890-94c8-72e2cfc8d380@oracle.com> <98dbdaa2-2d77-8404-d28b-779fca52704d@oracle.com> <08c0b540-dc74-512e-f82f-981173c4fc24@oracle.com> <101c2884-72ef-bfdd-ee0f-1c56298b507d@oracle.com> <845ebff8-df65-42ca-9761-f49163ebfef8@oracle.com> <478f8af8-78f8-3ef3-3ba0-e061bbdc39f0@oracle.com> <3725de19-babb-405c-714c-fc54b426fd02@oracle.com> <0ba60343-bf4d-fdef-ab13-cae04f9bf6ff@oracle.com> Message-ID: Thanks David. Coleen On 8/16/20 9:54 PM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 15/08/2020 8:59 pm, Coleen Phillimore wrote: >> >> >> On 8/14/20 7:58 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> I suggest just leaving the elfFile stuff alone. AFAICS the >>> underlying offset is 32-bit on 32-bit and 64-bit on 64-bit and on >>> the platforms we use ElfFile the use of "long" matches that (ILP32 >>> and LP64). This code should probably be using some of the Elf types >>> directly, hidden by a typedef to hide the 32-bit versus 64-bit >>> nomenclature. >> >> Ok, I reverted elfFile.* also. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8235765.03/webrev >> >> Thanks! >> Coleen >>> >>> David >>> >>> On 15/08/2020 9:19 am, David Holmes wrote: >>>> On 13/08/2020 10:20 pm, Coleen Phillimore wrote: >>>>> On 8/13/20 12:07 AM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> And it seemed so simple when you started :) >>>>> >>>>> Oh gosh no, this sort of change is never simple! >>>>>> >>>>>> On 13/08/2020 6:43 am, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Vladimir,? Thank you for looking at this change. >>>>>>> >>>>>>> On 8/12/20 1:25 PM, Vladimir Kozlov wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> I think it is safe to use 'uint' (uint32_t) for all counts in >>>>>>>> sweeper. >>>>>> >>>>>> "long" is only 32-bit on 64-bit Windows, so if we don't see any >>>>>> issues on Windows then there is a case to be made that all these >>>>>> long fields would appear to be fine if only 32-bit ... that said >>>>>> some of them "obviously" look like they should be size_t as you >>>>>> have made them. >>>>>> >>>>>>>> What is a story about using int64_t vs jlong? And others *_t vs >>>>>>>> j* types. >>>>>>> >>>>>>> jlong is a signed type (either long or long long) so in mutex, >>>>>>> even > though uint64_t makes more sense, I used int64_t so that >>>>>>> they'd be >>>>>>> convertible to jlong in the PlatformMutex layer.? I didn't want >>>>>>> to pull the string of this sweater even further to convert the >>>>>>> jlong to uint64_t in that layer. (If that's even the right thing >>>>>>> to do).? We have been trying to avoid using java types like >>>>>>> jint, jlong etc, in shared code, but they're pretty much >>>>>>> everywhere. >>>>>> >>>>>> We've been avoiding unnecessary use of j* types in the VM (shared >>>>>> or not) but when the values represent values to/from Java code >>>>>> then the j* types are appropriate. The multiple abstractions >>>>>> Parker/ParkEvent/PlatformEvent/PlatformParker/PlatformMonitor/Monitor >>>>>> make it hard to see exactly how values flow through, and which >>>>>> ones come direct from Java. We should keep the jlong at the >>>>>> Java-connected api level and use uint64_t elsewhere. Separate RFE >>>>>> of course. :) >>>>> >>>>> Yes, another sort of hard-to-impossible to completely fix RFE.? I >>>>> really think we should just fix individual occurrences as they're >>>>> found and discourage new uses. Ideally we should translate all j* >>>>> types to their appropriate int types once they get passed into the >>>>> VM implementation code. >>>>>> >>>>>> >>>>>> Looking at webrev v02: >>>>>> >>>>>> src/hotspot/share/memory/filemap.hpp >>>>>> >>>>>> You changed the field from long to int64_t but you didn't change >>>>>> the accessor: >>>>>> >>>>>> 87?? long?? filesize()? const { return _filesize; } >>>>> >>>>> Rats missed one.? I wish the compiler would have complained about >>>>> this. Nothing calls this function so I removed it (_filesize is >>>>> used directly). >>>> >>>> Ok. >>>> >>>>>> >>>>>> that could give a truncation warning on Windows. That field is >>>>>> set from the stat st_size field, which is defined as type off_t >>>>>> on non-Windows and as ... okay I can't make sense of the win32 >>>>>> docs to figure out whether a plain stat will be a 64-bit or >>>>>> 32-bit [1]. So not clear what the right type is here - but the >>>>>> field and accessor should match. >>>>>> >>>>>> [1] >>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019 >>>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/utilities/elfFile.cpp >>>>>> >>>>>> fseek is specified to take a long for the offset, so this change >>>>>> would be a problem on 32-bit builds I think. >>>>> >>>>> These files aren't compiled on windows.? I compiled this on arm32. >>>>> I think there "long" is 64 bits. >>>> >>>> No "long" is 32-bit on all 32-bit platforms. So I would expect >>>> passing a 64-bit value to a library function expecting a 32-bit >>>> argument should generate a compiler warning at best. The fact it >>>> doesn't is a concern. I'd be worried about the correctness of this >>>> code now. >>>> >>>> David >>>> >>>> >>>>> #if !defined(_WINDOWS) && !defined(__APPLE__) >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> Also you need to look on JFR code which collect these data: >>>>>>>> >>>>>>>> src/hotspot//share/jfr/periodic/jfrPeriodic.cpp: >>>>>>>> event.set_methodReclaimedCount(NMethodSweeper::total_nof_methods_reclaimed()); >>>>>>>> >>>>>>>> >>>>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>>>> name="methodReclaimedCount" label="Methods Reclaimed" /> >>>>>>>> >>>>>>>> And I found that metadata.xml have several 'long' uses too: >>>>>>>> >>>>>>>> src/hotspot//share/jfr/metadata/metadata.xml: >>>>>>> type="long" contentType="millis" name="peakTimeSpent" >>>>>>>> label="Peak Time" /> >>>>>>>> >>>>>>>> Looking on codecache code and sweeper and I see a lot of >>>>>>>> inconsistencies in used types :( >>>>>>>> May be we need an other (compiler) RFE to clean that up. >>>>>>> >>>>>>> Yes, I agree. I'm going to revert sweeper, nmethod and >>>>>>> vmStructs. It's better that 'long' is fixed individually in the >>>>>>> sweeper and associated files. >>>>>>> >>>>>>> The JFR metadata.xml has a lot of "long" types declared in it. >>>>>>> I'm going to revert compileBroker.* too.?? This is going to have >>>>>>> to be fixed a little at a time. >>>>>>> >>>>>>> I'm testing a new more limited version of this change now. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vladimir K >>>>>>>> >>>>>>>> On 8/12/20 10:00 AM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/12/20 12:19 PM, Lois Foltan wrote: >>>>>>>>>> On 8/12/2020 11:21 AM, Coleen Phillimore wrote: >>>>>>>>>>> Summary: Changed some long declarations to uint64_t/int64_t >>>>>>>>>>> or unsigned int, depending on context. >>>>>>>>>>> >>>>>>>>>>> There are still 'long' declarations left in the code, but >>>>>>>>>>> they should be changed by developers when working in that >>>>>>>>>>> code and not as a blanket change.? I didn't change a couple >>>>>>>>>>> of longs in jfr/leakprofiler, for example. These are the >>>>>>>>>>> ones I changed though with some explanation of why: >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/memory/filemap.hpp >>>>>>>>>>> >>>>>>>>>>> This can be negative so changed to int64_t. >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>> >>>>>>>>>>> The PlatformMutex code takes jlong, which is signed, so >>>>>>>>>>> that's why I changed these to int64_t. >>>>>>>>>>> >>>>>>>>>>> runtime/interfaceSupport.inline.hpp >>>>>>>>>>> >>>>>>>>>>> These counters are actually intervals so I changed them to >>>>>>>>>>> unsigned int. >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/compiler/compileBroker.hpp >>>>>>>>>>> >>>>>>>>>>> _peak_compilation_time is signed because it is compared with >>>>>>>>>>> jlong which is signed. >>>>>>>>>>> Same with total_compilation_time - >>>>>>>>>>> elapsedTimer.milliseconds() returns jlong. >>>>>>>>>>> >>>>>>>>>>> Tested with tier1-3.? Tier1 on linux-x64-debug, >>>>>>>>>>> windows-x64-debug, macosx-x64-debug, linux-aarch64-debug. >>>>>>>>>>> Also built on: >>>>>>>>>>> linux-arm32,linux-ppc64le-debug,linux-s390x-debug,linux-x64-zero. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> open webrev at >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8235765.01/webrev >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8235765 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> - runtime/sweeper.hpp >>>>>>>>>> ? This is the only file that I wondered why you changed long >>>>>>>>>> to int64_t for _total_nof_methods_reclaimed and >>>>>>>>>> _total_nof_c2_methods_reclaimed.? Note that the method >>>>>>>>>> NMethodSweeper::total_nof_methods_reclaimed returns an int. >>>>>>>>>> Could both of these fields be changed to int instead? >>>>>>>>> >>>>>>>>> Hi Lois, Thank you for looking at this. Unfortunately, this >>>>>>>>> was an outdated webrev, can you hit reload?? I changed these >>>>>>>>> fields to be uint64_t because they're never signed.? It's >>>>>>>>> likely that the number of methods is never greater than an >>>>>>>>> int, but since it was long to begin with, I kept 64 bit until >>>>>>>>> someone decides an 'int' is better. Since >>>>>>>>> number_of_codecache_sweeps is uint64_t, which seems like a lot >>>>>>>>> too, there could be that many nmethods reclaimed.? I retested >>>>>>>>> with windows just now to be sure. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lois >>>>>>>>> >>>>>>> >>>>> >> From akozlov at azul.com Mon Aug 17 16:01:07 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 17 Aug 2020 19:01:07 +0300 Subject: RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> Message-ID: <85475381-6c92-9d09-510f-d0b2cea3287f@azul.com> Hi all, > On 2020-08-17 14:28, Andrew Haley wrote: >> The JEP looks good to me. Thank you for the very fast response! Would you add yourself to the reviewers field? On 17.08.2020 16:17, Erik ?sterlund wrote: >> >> Re W^X: there are very few places where we now need runtime-patchable >> methods in the code cache. >> >> On AArch64, we deoptimize and recompile rather than patch in most >> cases. This is because the only instructions we're allowed to patch >> concurrently are direct jumps, traps, and nops. >> >> This leads to very little slowdown in practice because in a tiered- >> compilation-enabled JVM 90% of recompilations are due to tier >> escalation rather than patching needed, and most fields are resolved >> in the interpreter before C1 kicks in. >> >> The remaining places we patch today are >> nmethod::make_not_entrant_or_zombie and compiled inline caches for >> method calls. We can perhaps get rid of the first because we now have >> nmethod entry barriers, and Erik ?sterlund has been working on a >> replacement for inline caches. > > Right. The relevant JEP draft for these changes is here for interested readers: > https://bugs.openjdk.java.net/browse/JDK-8221828 > > In my current implementation prototype, all the above code patching has indeed been removed. > I still have the nmethod entry barriers, but as mentioned they do not patch anything on AArch64. > > Thanks, > /Erik > >> Finally, we would have to change the trampoline logic to go via a >> separate data table. >> >> I think that's it. Not that I'm suggesting you need this for Apple/ >> AArch64, but we're very close. These new mechanisms (nmethods barriers and new invoke binding) are certainly interesting and worth studying. I suppose the idea is to place volatile information to the metaspace instead of the codecache, so it can be patched more freely. But I need to read about these more carefully. Thanks for pointing! Modifying code in runtime is a part of the problem, another is that some meta information is stored in the codecache as well. For example, an allocation of a new code blob requires write capability to the code cache (allocator's data is near the blob). And blobs such as native adapters may be allocated and filled in on-demand, in a runtime call on a java thread, one that executed generated code before the call. Fortunately, it appears that Apple hasn't meant to break self-modifying programs, so they've introduced a mechanism (pthread_jit_write_protect_np[1]) that allows seeing pages as writable or executable depending on a state of the current thread, not a state of the target page. This ability may make the W^X implementation more straightforward and more boring than expected :) Thanks, Anton [1] https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon?language=objc From vladimir.kozlov at oracle.com Mon Aug 17 17:22:48 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Aug 2020 10:22:48 -0700 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> Message-ID: <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> Hi Kim, Looks good to me. On 8/17/20 3:32 AM, Kim Barrett wrote: > Please review this followup to JDK-8247976 [1], rehoming the information > from two subpages of the wiki Style Guide to jdk/jdk/doc. > > The "Naming HotSpot JTReg Tests" wiki page has been summarized as an > additional small section in the HotSpot Style Guide. I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 Someone from SQE need to comment about this if it is requirement. Thanks, Vladimir K > > The "Native/Unit Test Development Guidelines" has been transferred wholesale > to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was > accomplished by cut-and-paste of the wiki page content to the new file, then > adding markdown annotations corresponding to the wiki page's formatting. No > significant modifications were made to the text, not even to correct typos > and other errors that seem obvious. I want to get the file in place before > doing any updates to the content. > > [1] https://bugs.openjdk.java.net/browse/JDK-8247976 > > I think this change doesn't modify the Style Guide in any substantive way, > so I think a simple review is sufficient, rather than needing to gather > consensus for the change from the Group Members. > > Once this change is pushed I'll update the wiki pages to note they are > obsolete and provide a forwarding pointer. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251888 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ > From igor.ignatyev at oracle.com Mon Aug 17 17:55:06 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 17 Aug 2020 10:55:06 -0700 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> Message-ID: <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> > On Aug 17, 2020, at 10:22 AM, Vladimir Kozlov wrote: > > Hi Kim, > > Looks good to me. +1 > > On 8/17/20 3:32 AM, Kim Barrett wrote: >> Please review this followup to JDK-8247976 [1], rehoming the information >> from two subpages of the wiki Style Guide to jdk/jdk/doc. >> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >> additional small section in the HotSpot Style Guide. > > I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: > http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 > > Someone from SQE need to comment about this if it is requirement. it's not a requirement per se, it's rather a guideline that make it easier to use an IDE to work w/ tests. there are however tests (even in compiler) which don't follow this and don't have package statement. in any case, Kim's RFR is for migration of the docs as-is, thus if we are to add this piece, it should be handled separately. -- Igor > > Thanks, > Vladimir K > >> The "Native/Unit Test Development Guidelines" has been transferred wholesale >> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >> accomplished by cut-and-paste of the wiki page content to the new file, then >> adding markdown annotations corresponding to the wiki page's formatting. No >> significant modifications were made to the text, not even to correct typos >> and other errors that seem obvious. I want to get the file in place before >> doing any updates to the content. >> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >> I think this change doesn't modify the Style Guide in any substantive way, >> so I think a simple review is sufficient, rather than needing to gather >> consensus for the change from the Group Members. >> Once this change is pushed I'll update the wiki pages to note they are >> obsolete and provide a forwarding pointer. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8251888 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ From Divino.Cesar at microsoft.com Mon Aug 17 18:46:54 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Mon, 17 Aug 2020 18:46:54 +0000 Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap In-Reply-To: <7a0f37fb-74e3-11d5-8b01-8ead174e13b5@oracle.com> References: , <7a0f37fb-74e3-11d5-8b01-8ead174e13b5@oracle.com> Message-ID: David, no problem. Thanks for reviewing the initial patch. Thomas, thank you for the review and the detailed explanation. 1-2) I can compile the patch locally with `make images`, but I had only tested it with tier1_part1, testing with the whole tier1 I see the two failed tests that you mention ??. I'll later send an updated patch following your suggestions. 3) Thanks for clarifying this. I'll wait to hear from the GC folks to confirm what must be done here and then send an updated patch. Thx, Cesar ________________________________ From: hotspot-gc-dev on behalf of David Holmes Sent: August 16, 2020 7:07 PM To: Thomas St?fe ; Cesar Soares Lucas Cc: hotspot-dev developers ; Brian Stafford ; Aditya Mandaleeka ; Hotspot-Gc-Dev Subject: Re: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap Cesar, Thomas, As this is no longer a simple code refactoring I'm withdrawing from the review process. I'm also about to go on a weeks vacation. Cheers, David On 16/08/2020 7:12 pm, Thomas St?fe wrote: > Hi Cesar, > > This is going in the right direction, but needs some more thinking. > > (ccing gc since gc devs may want to look at the argument parsing, see > remarks below) > > --- > > In my last mail I was kind of rough-sketching my idea, and did not count > on you taking it over verbatim, sorry. The assert I quoted had a number > of errors: > > 1) it missed the assert message. Therefore building your patch gets us > build errors. For the prototypes of assert, see utilities/debug.hpp. > > 2) The assert I quoted was wrong since it also fires for special == > false && _fd == -1 which is a valid combo. So, after building we now get > a crash right away. > > Allowed combinations: > > !special && _fd == -1 (anonymous, non-large-paged, this is 99% of > standard cases) > special && _fd == -1 (anonymous large paged memory) > !special && _fd != -1 (mapping over a file) > > Disallowed: > special == true && _fd != -1 (mapping over a file with large pages) > > So, the assert should be: > > assert(_fd == -1 || special == false, "wrong arguments") > > or perhaps clearer to read: > > --------------- > > 3) > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F2%2Fsrc%2Fhotspot%2Fshare%2Fgc%2Fshared%2FgcArguments.cpp.udiff.html&data=02%7C01%7CDivino.Cesar%40microsoft.com%7C20b43e78f0164c9995ec08d84252a4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332270013934920&sdata=ReQNkLfbqK8e5HWFGpo198oc4zQOE8%2Byyn3Prmgff68%3D&reserved=0 > > Unfortunately argument parsing is more complicated and now raises > additional questions. None of those are not the fault of your patch, > which only moves logic out of ReservedSpace to arg parsing. > > + if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { > + jio_fprintf(defaultStream::error_stream(), > + "AllocateHeapAt and UseLargePages cannot be used together.\n"); > + status = false; > + } > > 3.1) You disallow using AllocateHeapAt and UseLargePages at the same > time. You use !FLAG_IS_DEFAULT(AllocateHeapAt), similar to code above > and below. But I think it is irrelevant whether the user did explicitly > specify that flag. If you were to change the default value for > AllocateHeapAt to a non-NULL value - for whatever weird reason - it > would still be wrong. > > I think you can just remove the FLAG_IS_DEFAULT and fall back to: > > - if (!FLAG_IS_DEFAULT(AllocateHeapAt) && UseLargePages) { > + if (AllocateHeapAt != NULL && UseLargePages) { > > And I think the same logic applies to AllocateOldGenAt, and affects the > other code in this function. > > 3.2) There is a tiny difference now as to how we treat TPH. > > Large pages come, at linux, in two flavours: UseHugeTLBFS and > UseTransparentHugePages. The former are explicit pinned pages, the > latter uses TPH. When UseTransparentHugePages is active, > os::can_commit_large_page_memory() returns true (actually, this is the > only case on all platforms where this is true). > > So, the patch causes AllocateHeapAt to be disallowed also for > transparent huge pages. Before, that combination would be allowed. Now > it's forbidden. > > But I am not sure whether this combination is in any way relevant, or if > it could even work. Especially on persistent memory which was the reason > AllocateHeapAt was introduced. Digging into gcArguments.cpp, I believe > it is not considered relevant, since at lines 63ff, I find: > > if (!FLAG_IS_DEFAULT(AllocateOldGenAt)) { > ..... > // When AllocateOldGenAt is set, we cannot use largepages for > entire heap memory. > // Only young gen which is allocated in dram can use large pages, > but we currently don't support that. > FLAG_SET_DEFAULT(UseLargePages, false); <-- > } > > which unconditionally switches off large pages for AllocateOldGenAt. > Since AllocateOldGetAt is very similar to AllocateHeapAt, disallowing > large pages for AllocateHeapAt - TPH or not - should be also fine. > > 3.3) which brings me to the next question: should we disallow this flag > combination and exit with an error, like your patch does now, or should > we quietly disable large pages instead and go on, like lines 63ff does > for AllocateOldGenAt? > > I believe the latter would be better, but I leave this to gc people to > answer. > > ------------------- > > Finally, a jtreg test may be good, testing the expected behaviour (which > kind of depends on the answer to question 3.3). For examples, see the > various tests at test/hotspot/jtreg/gc/arguments. > > ----- > > Sorry if this balloons a bit. I think this cleanup is very worthwhile. > > Cheers, Thomas > > > > > > > > On Sat, Aug 15, 2020 at 10:03 PM Cesar Soares Lucas > > wrote: > > Hi David/Thomas, > > Please see updated webrev here: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F2%2F&data=02%7C01%7CDivino.Cesar%40microsoft.com%7C20b43e78f0164c9995ec08d84252a4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332270013944916&sdata=UZ5z6014pawby%2BQEehY%2FkJv4V4PD3X3O64YIEHsb94A%3D&reserved=0 > > - I added a validation for `AllocateHeapAt and UseLargePages` in > `src/hotspot/share/gc/shared/gcArguments.cpp` because there was > some similar > validation there. Please advise if this isn't the best place to > put such validation. > > - I renamed `_fd_for_heap` to `_fd` in `virtualspace.*` following > your suggestion > in the previous e-mail. > > - Refactored the code in `virtualspace.*` according to the previous > e-mail and the > changes above. > > > Thanks for looking into this! > Cesar? > > ------------------------------------------------------------------------ > *From:* hotspot-dev > on behalf of Cesar > Soares Lucas > > *Sent:* August 12, 2020 10:41 AM > *To:* Thomas St?fe >; David Holmes > > > *Cc:* hotspot-dev developers >; Brian Stafford > >; Aditya Mandaleeka > > > *Subject:* Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > Thanks for reviewing this David and Thomas. > > Thomas, the error log messages were also confusing to me. I'll > refactor the code according to your suggestion and get back to you. > > > ________________________________ > From: Thomas St?fe > > Sent: August 11, 2020 11:14 PM > To: David Holmes > > Cc: Cesar Soares Lucas >; hotspot-dev developers > >; Brian Stafford > >; Aditya Mandaleeka > > > Subject: Re: RFR: 8244801 - Code duplication in > ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > Man ReservedSpace really should get a revamp. It is a general > purpose device, but so polluted with GC/java heap assumptions :( > > I think this can be done better. Let's look at it: > > // If OS doesn't support demand paging for large page memory, we > need > // to use reserve_memory_special() to reserve and pin the entire > region. > // If there is a backing file directory for this space then whether > // large pages are allocated is up to the filesystem of the > backing file. > // So we ignore the UseLargePages flag in this case. > bool special = large && !os::can_commit_large_page_memory(); > if (special && _fd_for_heap != -1) { > special = false; > if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) || > !FLAG_IS_DEFAULT(LargePageSizeInBytes))) { > log_debug(gc, heap)("Ignoring UseLargePages since large page > support is up to the file system of the backing file for Java heap"); > } > } > > So, IIUC: > > - Caller requested large pages (since large=true). Note that caller > can be anyone, does not have to be the one allocating java heap. > - The OS cannot commit large pages on demand (AFAICS only possible > on Linux TPH). So we need to explicitly reserve large paged pinned > memory, which we call "special" for some reason. > - But someone specified fd_for_heap (why "fd_for_heap"? This is a > general purpose API. Why so much GC/heap specific code?). So we deny > the request and feel this is worth an error message. > > The error messages conflict: one says basically "we ignore this but > the underlying file system may be larged paged, so you still may be > good, I don't know". One says "We ignore this, period.". > > So the problem worth reporting back to the user is that he specified > manually both -XX:+UseLargePages and -XX:AllocateHeapAt And that is > supposed to be a user error. It would be much clearer if that > conflict would be handled at argument parsing time, not here. Then > this code could just be: > > bool special = large && !os::can_commit_large_page_memory(); > assert(special || _fd_for_heap != -1); > > That would be cleaner and remove at least some of the "it's used for > heap allocations" assumptions from ReservedSpace. We could even > rename "fd_for_heap" to a general "fd" and just make it a general > argument (so, independent of AllocateHeapAt). Because someone other > than java heap might want to reserve memory atop of a file. > > Just my 5 cent. Sorry for the slight rant. > > Cheers, Thomas > > > > On Wed, Aug 12, 2020 at 6:42 AM David Holmes > >> wrote: > Hi Cesar, > > This seems fine to me and I can sponsor it for you once we have a second > review. > > Thanks, > David > > On 12/08/2020 12:27 pm, Cesar Soares Lucas wrote: > > Gentle ping. Can anyone PTAL? > > > > > > Thanks, > > Cesar > > > > ________________________________ > > From: hotspot-dev >> on behalf of Cesar > Soares Lucas >> > > Sent: August 6, 2020 2:30 PM > > To: hotspot-dev developers >> > > Cc: Brian Stafford >>; Aditya Mandaleeka > >> > > Subject: RFR: 8244801 - Code duplication in ReservedSpace::initialize/ReservedHeapSpace::try_reserve_heap > > > > > > Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244801&data=02%7C01%7CDivino.Cesar%40microsoft.com%7C20b43e78f0164c9995ec08d84252a4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332270013944916&sdata=RQD6huZq0oUnUYGJdje4TqrIYIPOS4%2BJg5TLeRGrrBA%3D&reserved=0 > > > Webrev: https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fcr.openjdk.java.net%2F~adityam%2Fcesar%2F8244801%2F0%2F&data=02%7C01%7CDivino.Cesar%40microsoft.com%7C20b43e78f0164c9995ec08d84252a4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332270013944916&sdata=gkvEJSiOIqrUL22EsDew2yoYsFPPq%2FDC9iD7V4yLgdw%3D&reserved=0 > > > Need sponsor: Yes > > > > Can you please review the above linked patch for the mentioned bug? > > It's a small change that refactor a portion of duplicated code in `virtualspace.cpp`. > > > > I tried to structure the code so that the new code and the old printed the same > > log messages. Please let me know if you want to simplify the method signature > > and just hard code the log message. I also tried to come up with a short yet > > descriptive name for the method; let me know if you have suggestions on that > > as well. > > > > > > Thanks, > > Cesar > > Software Engineer - Microsoft > > > From david.holmes at oracle.com Tue Aug 18 02:47:30 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2020 12:47:30 +1000 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> Message-ID: <92d00c54-83d8-cba1-19c7-abc36fa37fa1@oracle.com> On 18/08/2020 3:55 am, Igor Ignatyev wrote: >> On Aug 17, 2020, at 10:22 AM, Vladimir Kozlov wrote: >> >> Hi Kim, >> >> Looks good to me. > +1 >> >> On 8/17/20 3:32 AM, Kim Barrett wrote: >>> Please review this followup to JDK-8247976 [1], rehoming the information >>> from two subpages of the wiki Style Guide to jdk/jdk/doc. >>> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >>> additional small section in the HotSpot Style Guide. >> >> I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: >> http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 >> >> Someone from SQE need to comment about this if it is requirement. > it's not a requirement per se, it's rather a guideline that make it easier to use an IDE to work w/ tests. there are however tests (even in compiler) which don't follow this and don't have package statement. in any case, Kim's RFR is for migration of the docs as-is, thus if we are to add this piece, it should be handled separately. Agreed. FWIW putting tests in packages is an unnecessary encumberance IMO (and no I never use an IDE so ...). It makes it hard to run tests manually and harder for tests that want to switch out versions of classes at runtimes by changing classpath. I've been advocating removing unneccessary package use in our tests when I see them. Cheers, David > -- Igor > >> >> Thanks, >> Vladimir K >> >>> The "Native/Unit Test Development Guidelines" has been transferred wholesale >>> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >>> accomplished by cut-and-paste of the wiki page content to the new file, then >>> adding markdown annotations corresponding to the wiki page's formatting. No >>> significant modifications were made to the text, not even to correct typos >>> and other errors that seem obvious. I want to get the file in place before >>> doing any updates to the content. >>> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >>> I think this change doesn't modify the Style Guide in any substantive way, >>> so I think a simple review is sufficient, rather than needing to gather >>> consensus for the change from the Group Members. >>> Once this change is pushed I'll update the wiki pages to note they are >>> obsolete and provide a forwarding pointer. >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8251888 >>> Webrev: >>> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ > From shade at redhat.com Tue Aug 18 07:07:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Aug 2020 09:07:23 +0200 Subject: RFR (XS) 8251924: 32-bit build failures after JDK-8235765 Message-ID: <73773745-fc3f-3cec-4324-392b94eb65d5@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8251924 Fix: diff -r f74d10596242 src/hotspot/share/oops/klassVtable.cpp --- a/src/hotspot/share/oops/klassVtable.cpp Mon Aug 17 18:58:20 2020 -0700 +++ b/src/hotspot/share/oops/klassVtable.cpp Tue Aug 18 08:59:31 2020 +0200 @@ -1608,9 +1608,10 @@ size_t klassItable::_total_size; // Total no. of bytes used for itables void klassItable::print_statistics() { tty->print_cr("itable statistics:"); tty->print_cr("%6d classes with itables", _total_classes); - tty->print_cr("%6lu K uses for itables (average by class: %ld bytes)", _total_size / K, _total_size / _total_classes); + tty->print_cr(SIZE_FORMAT_W(6) " K uses for itables (average by class: " SIZE_FORMAT " bytes)", + _total_size / K, _total_size / _total_classes); } Testing: Linux {x86_64, x86_32} builds; eyeballing -XX:+PrintVtableStats output -- Thanks, -Aleksey From david.holmes at oracle.com Tue Aug 18 07:29:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2020 17:29:19 +1000 Subject: RFR (XS) 8251924: 32-bit build failures after JDK-8235765 In-Reply-To: <73773745-fc3f-3cec-4324-392b94eb65d5@redhat.com> References: <73773745-fc3f-3cec-4324-392b94eb65d5@redhat.com> Message-ID: <356063b0-f949-1484-a623-10c176383c11@oracle.com> Looks good and trivial. Thanks Aleksey! David On 18/08/2020 5:07 pm, Aleksey Shipilev wrote: > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8251924 > > Fix: > > diff -r f74d10596242 src/hotspot/share/oops/klassVtable.cpp > --- a/src/hotspot/share/oops/klassVtable.cpp??? Mon Aug 17 18:58:20 2020 > -0700 > +++ b/src/hotspot/share/oops/klassVtable.cpp??? Tue Aug 18 08:59:31 2020 > +0200 > @@ -1608,9 +1608,10 @@ > ?size_t klassItable::_total_size;????? // Total no. of bytes used for > itables > > ?void klassItable::print_statistics() { > ? tty->print_cr("itable statistics:"); > ? tty->print_cr("%6d classes with itables", _total_classes); > - tty->print_cr("%6lu K uses for itables (average by class: %ld bytes)", > _total_size / K, _total_size / _total_classes); > + tty->print_cr(SIZE_FORMAT_W(6) " K uses for itables (average by class: > " SIZE_FORMAT " bytes)", > +?????????????? _total_size / K, _total_size / _total_classes); > ?} > > Testing: Linux {x86_64, x86_32} builds; eyeballing -XX:+PrintVtableStats > output > From kim.barrett at oracle.com Tue Aug 18 07:38:37 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 18 Aug 2020 03:38:37 -0400 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> Message-ID: <69AED8A9-9A30-4997-AB48-558438AF8A2F@oracle.com> > On Aug 17, 2020, at 1:55 PM, Igor Ignatyev wrote: > > > >> On Aug 17, 2020, at 10:22 AM, Vladimir Kozlov wrote: >> >> Hi Kim, >> >> Looks good to me. > +1 Thanks. >> >> On 8/17/20 3:32 AM, Kim Barrett wrote: >>> Please review this followup to JDK-8247976 [1], rehoming the information >>> from two subpages of the wiki Style Guide to jdk/jdk/doc. >>> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >>> additional small section in the HotSpot Style Guide. >> >> I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: >> http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 >> >> Someone from SQE need to comment about this if it is requirement. > it's not a requirement per se, it's rather a guideline that make it easier to use an IDE to work w/ tests. there are however tests (even in compiler) which don't follow this and don't have package statement. in any case, Kim's RFR is for migration of the docs as-is, thus if we are to add this piece, it should be handled separately. Yes, this is intended to be just a re-homing change, with no substantive changes to content. > > -- Igor > >> >> Thanks, >> Vladimir K >> >>> The "Native/Unit Test Development Guidelines" has been transferred wholesale >>> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >>> accomplished by cut-and-paste of the wiki page content to the new file, then >>> adding markdown annotations corresponding to the wiki page's formatting. No >>> significant modifications were made to the text, not even to correct typos >>> and other errors that seem obvious. I want to get the file in place before >>> doing any updates to the content. >>> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >>> I think this change doesn't modify the Style Guide in any substantive way, >>> so I think a simple review is sufficient, rather than needing to gather >>> consensus for the change from the Group Members. >>> Once this change is pushed I'll update the wiki pages to note they are >>> obsolete and provide a forwarding pointer. >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8251888 >>> Webrev: >>> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ From kim.barrett at oracle.com Tue Aug 18 07:39:09 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 18 Aug 2020 03:39:09 -0400 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> Message-ID: <3754D5A1-3A81-4A73-AC66-50CE429D9184@oracle.com> > On Aug 17, 2020, at 1:22 PM, Vladimir Kozlov wrote: > > Hi Kim, > > Looks good to me. Thanks. > > On 8/17/20 3:32 AM, Kim Barrett wrote: >> Please review this followup to JDK-8247976 [1], rehoming the information >> from two subpages of the wiki Style Guide to jdk/jdk/doc. >> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >> additional small section in the HotSpot Style Guide. > > I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: > http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 > > Someone from SQE need to comment about this if it is requirement. See Igor?s reply. > > Thanks, > Vladimir K > >> The "Native/Unit Test Development Guidelines" has been transferred wholesale >> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >> accomplished by cut-and-paste of the wiki page content to the new file, then >> adding markdown annotations corresponding to the wiki page's formatting. No >> significant modifications were made to the text, not even to correct typos >> and other errors that seem obvious. I want to get the file in place before >> doing any updates to the content. >> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >> I think this change doesn't modify the Style Guide in any substantive way, >> so I think a simple review is sufficient, rather than needing to gather >> consensus for the change from the Group Members. >> Once this change is pushed I'll update the wiki pages to note they are >> obsolete and provide a forwarding pointer. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8251888 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ From kim.barrett at oracle.com Tue Aug 18 07:42:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 18 Aug 2020 03:42:38 -0400 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <92d00c54-83d8-cba1-19c7-abc36fa37fa1@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> <92d00c54-83d8-cba1-19c7-abc36fa37fa1@oracle.com> Message-ID: <0F317760-70D1-4CC6-B19B-E8529BC651A7@oracle.com> > On Aug 17, 2020, at 10:47 PM, David Holmes wrote: > > On 18/08/2020 3:55 am, Igor Ignatyev wrote: >>> On Aug 17, 2020, at 10:22 AM, Vladimir Kozlov wrote: >>> >>> Hi Kim, >>> >>> Looks good to me. >> +1 >>> >>> On 8/17/20 3:32 AM, Kim Barrett wrote: >>>> Please review this followup to JDK-8247976 [1], rehoming the information >>>> from two subpages of the wiki Style Guide to jdk/jdk/doc. >>>> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >>>> additional small section in the HotSpot Style Guide. >>> >>> I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: >>> http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 >>> >>> Someone from SQE need to comment about this if it is requirement. >> it's not a requirement per se, it's rather a guideline that make it easier to use an IDE to work w/ tests. there are however tests (even in compiler) which don't follow this and don't have package statement. in any case, Kim's RFR is for migration of the docs as-is, thus if we are to add this piece, it should be handled separately. > > Agreed. FWIW putting tests in packages is an unnecessary encumberance IMO (and no I never use an IDE so ...). It makes it hard to run tests manually and harder for tests that want to switch out versions of classes at runtimes by changing classpath. I've been advocating removing unneccessary package use in our tests when I see them. Seems we have an actual disagreement over that usage, so I definitely don?t want to do anything about it with this change. > > Cheers, > David > > >> -- Igor >>> >>> Thanks, >>> Vladimir K >>> >>>> The "Native/Unit Test Development Guidelines" has been transferred wholesale >>>> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >>>> accomplished by cut-and-paste of the wiki page content to the new file, then >>>> adding markdown annotations corresponding to the wiki page's formatting. No >>>> significant modifications were made to the text, not even to correct typos >>>> and other errors that seem obvious. I want to get the file in place before >>>> doing any updates to the content. >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >>>> I think this change doesn't modify the Style Guide in any substantive way, >>>> so I think a simple review is sufficient, rather than needing to gather >>>> consensus for the change from the Group Members. >>>> Once this change is pushed I'll update the wiki pages to note they are >>>> obsolete and provide a forwarding pointer. >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8251888 >>>> Webrev: >>>> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ From shade at redhat.com Tue Aug 18 10:46:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Aug 2020 12:46:44 +0200 Subject: RFR (XS) 8251924: 32-bit build failures after JDK-8235765 In-Reply-To: <356063b0-f949-1484-a623-10c176383c11@oracle.com> References: <73773745-fc3f-3cec-4324-392b94eb65d5@redhat.com> <356063b0-f949-1484-a623-10c176383c11@oracle.com> Message-ID: <9824f4f6-df75-29cf-9bf3-7cd3d2854e78@redhat.com> On 8/18/20 9:29 AM, David Holmes wrote: > Looks good and trivial. Thanks Aleksey! Thanks. jdk-submit came clean. I pushed. -- -Aleksey From akozlov at azul.com Tue Aug 18 15:21:53 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 18 Aug 2020 18:21:53 +0300 Subject: RFR(s): 8251930: AArch64: Native types mismatch in hotspot Message-ID: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Hi, Could you please review a fix for C++ types mismatch in cpu/aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8251930 Webrev: http://cr.openjdk.java.net/~akozlov/8251930/webrev.00/ The issue was discovered by trying to compile by aarch64-darwin toolchain, but it just uncovered a more general problem. Extra method overloads with for int, long, ... are added to catch all (suitable) types used for intptr_t, int64_t. Now there are overloads only for int (for literal values) and int64, latter usually shares a fundamental type with intptr. The new toolchain provides different types for int64 and intptr. Then both overloads are not perfect for an intptr argument but possible, so compilation is failed. Providing additional overload for intptr fixes compilation on new toolchain but breaks linux, as intptr and int64 are different overloads for essentially the same type. Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. Tested on aarch64-darwin (succesfully compiles cpu/aarch64 code) and aarch64-linux toolchains. Thanks, Anton From vladimir.kozlov at oracle.com Tue Aug 18 15:31:10 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Aug 2020 08:31:10 -0700 Subject: RFR: 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc In-Reply-To: <0F317760-70D1-4CC6-B19B-E8529BC651A7@oracle.com> References: <9767D992-FD46-4B8C-B615-333BA18A9BE3@oracle.com> <6dcb45c3-58a4-1f45-3cfc-436e1273b6b8@oracle.com> <09881006-C207-48EE-8297-EF2C2CA49EA7@oracle.com> <92d00c54-83d8-cba1-19c7-abc36fa37fa1@oracle.com> <0F317760-70D1-4CC6-B19B-E8529BC651A7@oracle.com> Message-ID: On 8/18/20 12:42 AM, Kim Barrett wrote: >> On Aug 17, 2020, at 10:47 PM, David Holmes wrote: >> >> On 18/08/2020 3:55 am, Igor Ignatyev wrote: >>>> On Aug 17, 2020, at 10:22 AM, Vladimir Kozlov wrote: >>>> >>>> Hi Kim, >>>> >>>> Looks good to me. >>> +1 >>>> >>>> On 8/17/20 3:32 AM, Kim Barrett wrote: >>>>> Please review this followup to JDK-8247976 [1], rehoming the information >>>>> from two subpages of the wiki Style Guide to jdk/jdk/doc. >>>>> The "Naming HotSpot JTReg Tests" wiki page has been summarized as an >>>>> additional small section in the HotSpot Style Guide. >>>> >>>> I think we (in Compiler group at least) also have rules to specify package for each jtreg test to match sub-directories they are in: >>>> http://hg.openjdk.java.net/jdk/jdk/file/35dc23e2705a/test/hotspot/jtreg/compiler/allocation/TestAllocation.java#l34 >>>> >>>> Someone from SQE need to comment about this if it is requirement. >>> it's not a requirement per se, it's rather a guideline that make it easier to use an IDE to work w/ tests. there are however tests (even in compiler) which don't follow this and don't have package statement. in any case, Kim's RFR is for migration of the docs as-is, thus if we are to add this piece, it should be handled separately. >> >> Agreed. FWIW putting tests in packages is an unnecessary encumberance IMO (and no I never use an IDE so ...). It makes it hard to run tests manually and harder for tests that want to switch out versions of classes at runtimes by changing classpath. I've been advocating removing unneccessary package use in our tests when I see them. > > Seems we have an actual disagreement over that usage, so I definitely don?t want to do > anything about it with this change. Agree. Thanks, Vladimir K > >> >> Cheers, >> David >> >> >>> -- Igor >>>> >>>> Thanks, >>>> Vladimir K >>>> >>>>> The "Native/Unit Test Development Guidelines" has been transferred wholesale >>>>> to a new file: jdk/jdk/doc/hotspot-unit-tests.{md,html}. This transfer was >>>>> accomplished by cut-and-paste of the wiki page content to the new file, then >>>>> adding markdown annotations corresponding to the wiki page's formatting. No >>>>> significant modifications were made to the text, not even to correct typos >>>>> and other errors that seem obvious. I want to get the file in place before >>>>> doing any updates to the content. >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247976 >>>>> I think this change doesn't modify the Style Guide in any substantive way, >>>>> so I think a simple review is sufficient, rather than needing to gather >>>>> consensus for the change from the Group Members. >>>>> Once this change is pushed I'll update the wiki pages to note they are >>>>> obsolete and provide a forwarding pointer. >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8251888 >>>>> Webrev: >>>>> https://cr.openjdk.java.net/~kbarrett/8251888/open.00/ > > From beurba at microsoft.com Tue Aug 18 19:43:25 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 18 Aug 2020 19:43:25 +0000 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: Hi Anton, > Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. That's how I did it initially, but it's quite a noisy patch and in reality doesn't add any value, so I prefer your solution. I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. Otherwise your change looks good (but I'm not a reviewer :-)). Thanks, -Bernhard [1] https://bugs.openjdk.java.net/browse/JDK-8248414 ________________________________________ From: aarch64-port-dev on behalf of Anton Kozlov Sent: Tuesday, August 18, 2020 17:21 To: hotspot-dev at openjdk.java.net Cc: aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot Hi, Could you please review a fix for C++ types mismatch in cpu/aarch64. Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8251930&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=jgh%2FFoiw2n80g54p%2B8WyrODMswn9Hst0gt3eVnn2%2B%2BY%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~akozlov%2F8251930%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=IKEdHXv0rIK4DqVqDfI%2BN2o7ArwctDiltSRi8vmvP0Y%3D&reserved=0 The issue was discovered by trying to compile by aarch64-darwin toolchain, but it just uncovered a more general problem. Extra method overloads with for int, long, ... are added to catch all (suitable) types used for intptr_t, int64_t. Now there are overloads only for int (for literal values) and int64, latter usually shares a fundamental type with intptr. The new toolchain provides different types for int64 and intptr. Then both overloads are not perfect for an intptr argument but possible, so compilation is failed. Providing additional overload for intptr fixes compilation on new toolchain but breaks linux, as intptr and int64 are different overloads for essentially the same type. Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. Tested on aarch64-darwin (succesfully compiles cpu/aarch64 code) and aarch64-linux toolchains. Thanks, Anton From igor.ignatyev at oracle.com Tue Aug 18 23:42:19 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Aug 2020 16:42:19 -0700 Subject: RFR(T) : 8252005 : narrow disabling of allowSmartActionArgs in vmTestbase Message-ID: <4E6FECE6-9103-46ED-84B2-79DBA0123ED9@oracle.com> http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ > 0 lines changed: 0 ins; 0 del; 0 mod; Hi all, could you please review this trivial (and apparently empty) patch which sets allowSmartActionArgs to false only in subdirectories of vmTestbase which currently use PropertyResolvingWrapper? (it's hard to tell from webrev or patch, but test/hotspot/jtreg/vmTestbase/TEST.properties is effectively removed) webrev: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8252005 Thanks, -- Igor From akozlov at azul.com Wed Aug 19 08:55:47 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 11:55:47 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: Hi Bernhard, On 18.08.2020 22:43, Bernhard Urban-Forster wrote: > I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. I also would like to have explicit overloads for int32_t/64_t/intptr_t, but as I wrote it creates another issue. Consider a valid set of system types for LP64 (I think there are valid sets for LLP64 demonstrating the same): typedef int int32_t; typedef long int int64_t; typedef long int intptr_t; then mov(Register, int64_t) { /* overload 1 */ } mov(Register, intptr_t) { /* overload 2 */ } are multiple overloads for same the same set of arguments, so it won't compile. I don't like introducing fundamental types again too. But the patch treats both (long) and (long long) uniformly, so the code should work for LLP64 as well as for LP64. It was really surprising for me, how smooth the work went and why hadn't you solved the same problems in the latest JEP 388 patch, until I found 8248414 :-) These bugs are linked in JBS. Thanks, Anton From aph at redhat.com Wed Aug 19 08:45:18 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 09:45:18 +0100 Subject: RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> On 18/08/2020 16:21, Anton Kozlov wrote: > Extra method overloads with for int, long, ... are added to catch > all (suitable) types used for intptr_t, int64_t. Now there are > overloads only for int (for literal values) and int64, latter > usually shares a fundamental type with intptr. The new toolchain > provides different types for int64 and intptr. Well, that's very silly. Out of interest, what is the fundamental type? Or are they compiler builtins? > Then both overloads are not perfect for an intptr argument but > possible, so compilation is failed. Providing additional overload > for intptr fixes compilation on new toolchain but breaks linux, as > intptr and int64 are different overloads for essentially the same > type. I wonder what ISO C++ says about all of this. We are in danger of turning the code into an effectively unmaintainable mess because a Linux programmer makes a change, it breaks Darwin, and vice versa. Are there any compiler flags that might help here? > Another approach is to leave a single overload for integer type, but > literal integer could still be ambiguously promoted to e.g. pointer > or int64. So every user will have to explicitly cast literal > integers to a certain type. Maybe a template function for mov() ? Be careful with sign extension. We want to make sure mov(reg, -1) works correctly. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Wed Aug 19 09:42:39 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 12:42:39 +0300 Subject: RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> Message-ID: <907599c1-6040-2727-1bd1-239400827d3c@azul.com> On 19.08.2020 11:45, Andrew Haley wrote: > On 18/08/2020 16:21, Anton Kozlov wrote: > >> Extra method overloads with for int, long, ... are added to catch >> all (suitable) types used for intptr_t, int64_t. Now there are >> overloads only for int (for literal values) and int64, latter >> usually shares a fundamental type with intptr. The new toolchain >> provides different types for int64 and intptr. > > Well, that's very silly. Out of interest, what is the fundamental > type? Or are they compiler builtins? I mean int, long, long long, ... [1] intptr_t,int32_t,int64_t are usually typedef's of int,long,... Overloads operating on compiler (fundamental) types, not results of typedef. > >> Then both overloads are not perfect for an intptr argument but >> possible, so compilation is failed. Providing additional overload >> for intptr fixes compilation on new toolchain but breaks linux, as >> intptr and int64 are different overloads for essentially the same >> type. > > I wonder what ISO C++ says about all of this. We are in danger of > turning the code into an effectively unmaintainable mess because a > Linux programmer makes a change, it breaks Darwin, and vice versa. > > Are there any compiler flags that might help here? I don't think there is a flag for that. Once we provided an overload for (address) and e.g (int64_t), we need the rest set of overloads to capture (int) for literals, (intptr) that may be a type unrelated to (int64_t)... The process converges, I think. The provided overloads for mov() and Address() are reasonable upper bound. The only possibility to break a build is to call another function that provides some but not all overloads with an argument of a new type. The user will have to choose to cast the argument or to introduce overload. At the worst case, we would have a set of overloads for few widely used functions, following the pattern from this patch. I think there is always a chance to break a build by changing shared code, and cpu/aarch64 is becoming such. Fortunately, build failures are easy to detect and fix. > >> Another approach is to leave a single overload for integer type, but >> literal integer could still be ambiguously promoted to e.g. pointer >> or int64. So every user will have to explicitly cast literal >> integers to a certain type. > > Maybe a template function for mov() ? > > Be careful with sign extension. We want to make sure mov(reg, -1) > works correctly. > A template is interesting, it may save as a few lines and reduce the amount of choices to several. I'll try to do that. As for sign extension, that's why unsigned variants provided as well, so mov(r, -1) should choose mov(Register, int) and not mov(Register, unsigned int). Thanks, Anton [1] https://en.cppreference.com/w/cpp/language/types From beurba at microsoft.com Wed Aug 19 10:33:35 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 19 Aug 2020 10:33:35 +0000 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> , Message-ID: Argh, I only tried my suggestion on aarch64-darwin, but you are right, it causes issues on aarch64-linux and presumably on aarch64-win as well. Thanks for the explanation, -Bernhard ________________________________________ From: Anton Kozlov Sent: Wednesday, August 19, 2020 10:55 To: Bernhard Urban-Forster; hotspot-dev at openjdk.java.net Cc: aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot Hi Bernhard, On 18.08.2020 22:43, Bernhard Urban-Forster wrote: > I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. I also would like to have explicit overloads for int32_t/64_t/intptr_t, but as I wrote it creates another issue. Consider a valid set of system types for LP64 (I think there are valid sets for LLP64 demonstrating the same): typedef int int32_t; typedef long int int64_t; typedef long int intptr_t; then mov(Register, int64_t) { /* overload 1 */ } mov(Register, intptr_t) { /* overload 2 */ } are multiple overloads for same the same set of arguments, so it won't compile. I don't like introducing fundamental types again too. But the patch treats both (long) and (long long) uniformly, so the code should work for LLP64 as well as for LP64. It was really surprising for me, how smooth the work went and why hadn't you solved the same problems in the latest JEP 388 patch, until I found 8248414 :-) These bugs are linked in JBS. Thanks, Anton From akozlov at azul.com Wed Aug 19 13:10:21 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 16:10:21 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <907599c1-6040-2727-1bd1-239400827d3c@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: On 19.08.2020 12:42, Anton Kozlov wrote: > On 19.08.2020 11:45, Andrew Haley wrote: >> On 18/08/2020 16:21, Anton Kozlov wrote: >>> Another approach is to leave a single overload for integer type, but >>> literal integer could still be ambiguously promoted to e.g. pointer >>> or int64. So every user will have to explicitly cast literal >>> integers to a certain type. >> >> Maybe a template function for mov() ? >> > > A template is interesting, it may save as a few lines and reduce the amount of > choices to several. I'll try to do that. > A template is complicated by the existing mov(Register, Address) overload. We need a single template to capture all integer types and the other template or overload to handle Address() and its subclasses. For example template inline void mov(Register dst, T imm) { mov_immediate64(dst, (uint64_t)imm); } void mov(Register dst, Address a); doesn't compile for mov(r0, RuntimeAddress()) without an explicit cast of RuntimeAddress to Address. With C++14, it is possible to avoid casts with use something like enable_if[1], so the code in macroassembler would look like template::value>* = nullptr> void mov(Register r, T imm) { ... } template::value>* = nullptr> void mov(Register r, T addr) { ... } Compared to the current patch, I don't think such template would be less error-prone or more maintainable. I would stick to the current version. Thanks, Anton [1] https://en.cppreference.com/w/cpp/types/enable_if From christian.hagedorn at oracle.com Wed Aug 19 14:00:27 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 19 Aug 2020 16:00:27 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken Message-ID: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Hi Please review the following small patch which fixes the broken optimized build: https://bugs.openjdk.java.net/browse/JDK-8252037 http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ There are actually two build issues as shown in the bug description. Thank you! Best regards, Christian From zgu at redhat.com Wed Aug 19 14:34:51 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 19 Aug 2020 10:34:51 -0400 Subject: [16] RFR(XS) 8249144 Potential memory leak in TypedMethodOptionMatcher In-Reply-To: References: Message-ID: Fix "Subject" line, missed bug ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8249144 Thanks, -Zhengyu On 7/9/20 9:19 AM, Zhengyu Gu wrote: > TypedMethodOptionMatcher owns ccstr value (vs. os::strdup_check_oom()), > but never frees it in destructor. > > It does not appear to a real issue so far, because > TypedMethodOptionMatcher seems immortal. Given it releases _option > string, it should also release ccstr value. > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249144/webrev.00/ > > Test: > ? tier1_compiler on Linux x86_64 > ? Submit test in progress > > Thanks, > > -Zhengyu From vladimir.x.ivanov at oracle.com Wed Aug 19 14:42:35 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 19 Aug 2020 17:42:35 +0300 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: > http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ Looks good. Best regards, Vladimir Ivanov From thomas.schatzl at oracle.com Wed Aug 19 14:51:52 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 19 Aug 2020 16:51:52 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: On 19.08.20 16:42, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ > > Looks good. > > Best regards, > Vladimir Ivanov +1 Thomas From tobias.hartmann at oracle.com Wed Aug 19 15:04:18 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Aug 2020 17:04:18 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <974487b0-bd69-8a52-6d3e-ec43e77be5a5@oracle.com> +1 Best regards, Tobias On 19.08.20 16:42, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ > > Looks good. > > Best regards, > Vladimir Ivanov From aph at redhat.com Wed Aug 19 17:03:24 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 18:03:24 +0100 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: On 19/08/2020 14:10, Anton Kozlov wrote: > With C++14, it is possible to avoid casts with use something like enable_if[1], > so the code in macroassembler would look like > > template::value>* = nullptr> > void mov(Register r, T imm) { ... } > > template::value>* = nullptr> > void mov(Register r, T addr) { ... } > > Compared to the current patch, I don't think such template would be less > error-prone or more maintainable. I would stick to the current version. OK. I rather like the template version: it's clear to me what the intention is. But I agree it's marginal. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From serguei.spitsyn at oracle.com Wed Aug 19 23:22:08 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 19 Aug 2020 16:22:08 -0700 Subject: RFR(T) : 8252005 : narrow disabling of allowSmartActionArgs in vmTestbase In-Reply-To: <4E6FECE6-9103-46ED-84B2-79DBA0123ED9@oracle.com> References: <4E6FECE6-9103-46ED-84B2-79DBA0123ED9@oracle.com> Message-ID: <17a8369e-5f38-ebab-974b-28e083378aa2@oracle.com> Hi Igor, This looks reasonable. Thanks, Serguei On 8/18/20 16:42, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ >> 0 lines changed: 0 ins; 0 del; 0 mod; > Hi all, > > could you please review this trivial (and apparently empty) patch which sets allowSmartActionArgs to false only in subdirectories of vmTestbase which currently use PropertyResolvingWrapper? > > (it's hard to tell from webrev or patch, but test/hotspot/jtreg/vmTestbase/TEST.properties is effectively removed) > > webrev: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8252005 > > Thanks, > -- Igor > > From christian.hagedorn at oracle.com Thu Aug 20 07:16:52 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 20 Aug 2020 09:16:52 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <4e78f323-df81-ad9d-9d35-a39c47fd468f@oracle.com> Thank you Vladimir, Thomas and Tobias for your reviews! Best regards, Christian On 19.08.20 16:51, Thomas Schatzl wrote: > On 19.08.20 16:42, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ >> >> Looks good. >> >> Best regards, >> Vladimir Ivanov > > +1 > > Thomas On 19.08.20 17:04, Tobias Hartmann wrote> +1 > > Best regards, > Tobias From kim.barrett at oracle.com Thu Aug 20 08:57:07 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 20 Aug 2020 04:57:07 -0400 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: > On Aug 19, 2020, at 10:00 AM, Christian Hagedorn wrote: > > Hi > > Please review the following small patch which fixes the broken optimized build: > https://bugs.openjdk.java.net/browse/JDK-8252037 > http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ > > There are actually two build issues as shown in the bug description. > > Thank you! > > Best regards, > Christian I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the bug here is that these counters are being conditionally printed under PRODUCT, but should be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an optimized build in a while. [1] Quoting myself from a different recent review thread: The purpose of "optimized" builds (as explained to me by one of its long-time proponents) is to have the performance characteristics of a release build (so no extra checks that affect performance or timing), but provide additional tools and data (printers, names, &etc) that we want to exclude from a release build for reasons of saving space or whatever. There's certainly lots of confusion around it though. From christian.hagedorn at oracle.com Thu Aug 20 09:36:53 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 20 Aug 2020 11:36:53 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: Hi Kim On 20.08.20 10:57, Kim Barrett wrote: >> On Aug 19, 2020, at 10:00 AM, Christian Hagedorn wrote: >> >> Hi >> >> Please review the following small patch which fixes the broken optimized build: >> https://bugs.openjdk.java.net/browse/JDK-8252037 >> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ >> >> There are actually two build issues as shown in the bug description. >> >> Thank you! >> >> Best regards, >> Christian > > I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the > bug here is that these counters are being conditionally printed under PRODUCT, but should > be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an > optimized build in a while. Yes, it does not seem to be built that often. > > [1] Quoting myself from a different recent review thread: > The purpose of "optimized" builds (as explained to me by one of its > long-time proponents) is to have the performance characteristics of a > release build (so no extra checks that affect performance or timing), > but provide additional tools and data (printers, names, &etc) that we > want to exclude from a release build for reasons of saving space or > whatever. There's certainly lots of confusion around it though. I see, thanks for explaining the purpose of the optimized build in more detail - it was indeed a bit confusing. Then it makes sense to revert these related changes to keep these counters under the ASSERT and guard the logging with an additional ifdef ASSERT instead to fix the build issues. I updated that in a new webrev (the optimized build was successful with it): http://cr.openjdk.java.net/~chagedorn/8252037/webrev.01/ Best regards, Christian From magnus.ihse.bursie at oracle.com Thu Aug 20 10:18:38 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Aug 2020 12:18:38 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <069e495e-c49d-8bfa-b437-5f20b40ba195@oracle.com> On 2020-08-20 10:57, Kim Barrett wrote: >> On Aug 19, 2020, at 10:00 AM, Christian Hagedorn wrote: >> >> Hi >> >> Please review the following small patch which fixes the broken optimized build: >> https://bugs.openjdk.java.net/browse/JDK-8252037 >> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ >> >> There are actually two build issues as shown in the bug description. >> >> Thank you! >> >> Best regards, >> Christian > I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the > bug here is that these counters are being conditionally printed under PRODUCT, but should > be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an > optimized build in a while. > > [1] Quoting myself from a different recent review thread: > The purpose of "optimized" builds (as explained to me by one of its > long-time proponents) is to have the performance characteristics of a > release build (so no extra checks that affect performance or timing), > but provide additional tools and data (printers, names, &etc) that we > want to exclude from a release build for reasons of saving space or > whatever. There's certainly lots of confusion around it though. It's been a long time, low-priority issue to try and disentangle the bunch of? "tweaks" that optimized builds bring, so they can be turned on and off individually. This would allow us to scrap optimized builds, which often bit-rot since they are seldom used. Unfortunately, the low priority of this means that no progress at all has been made for I think several years. :-( There is a JBS issue somewhere which outlines what kind of work is needed. /Magnus > From vladimir.x.ivanov at oracle.com Thu Aug 20 11:38:16 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 20 Aug 2020 14:38:16 +0300 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: > I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the > bug here is that these counters are being conditionally printed under PRODUCT, but should > be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an > optimized build in a while. > > [1] Quoting myself from a different recent review thread: > The purpose of "optimized" builds (as explained to me by one of its > long-time proponents) is to have the performance characteristics of a > release build (so no extra checks that affect performance or timing), > but provide additional tools and data (printers, names, &etc) that we > want to exclude from a release build for reasons of saving space or > whatever. There's certainly lots of confusion around it though. Ultimately it's GC team call, but counters are extensively used in optimized build. It this respect, it's perfectly fine to expose add_obj_count and add_obj_bytes in optimized build. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Aug 20 11:42:33 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 20 Aug 2020 14:42:33 +0300 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <81184fb3-1d1a-a1ef-05fb-dbd40a7ba363@oracle.com> > http://cr.openjdk.java.net/~chagedorn/8252037/webrev.01/ Still looks good. I'm fine with both versions. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Aug 20 11:48:27 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 20 Aug 2020 14:48:27 +0300 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: <069e495e-c49d-8bfa-b437-5f20b40ba195@oracle.com> References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> <069e495e-c49d-8bfa-b437-5f20b40ba195@oracle.com> Message-ID: <28aa2956-6fbc-f386-575a-596b56e39878@oracle.com> >> [1] Quoting myself from a different recent review thread: >> The purpose of "optimized" builds (as explained to me by one of its >> long-time proponents) is to have the performance characteristics of a >> release build (so no extra checks that affect performance or timing), >> but provide additional tools and data (printers, names, &etc) that we >> want to exclude from a release build for reasons of saving space or >> whatever. There's certainly lots of confusion around it though. > It's been a long time, low-priority issue to try and disentangle the > bunch of? "tweaks" that optimized builds bring, so they can be turned on > and off individually. This would allow us to scrap optimized builds, > which often bit-rot since they are seldom used. Unfortunately, the low > priority of this means that no progress at all has been made for I think > several years. :-( There is a JBS issue somewhere which outlines what > kind of work is needed. This thread is probably not the best place to discuss it, but I don't see why wrapping the code and expose it as optional JVM feature will help avoid bit-rot. It can improve the code itself (choosing between "#ifdef ASSERT" and "#ifndef PRODUCT" is error-prone), but it won't make it built more frequently by itself. IMO the root cause is that optimized configuration is not built as part of any regular testing. And irrespective of how the code is shaped, it's required step to avoid bit-rot. Best regards, Vladimir Ivanov From thomas.schatzl at oracle.com Thu Aug 20 13:00:02 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 20 Aug 2020 15:00:02 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: Hi, On 20.08.20 13:38, Vladimir Ivanov wrote: > >> I think the changes to parallelgc are contrary to the intent of the >> optimized build [1].? I think the >> bug here is that these counters are being conditionally printed under >> PRODUCT, but should >> be printed under ASSERT.? That is, 8232686 wasn?t quite right.? I >> guess nobody has done an >> optimized build in a while. >> >> [1] Quoting myself from a different recent review thread: >> The purpose of "optimized" builds (as explained to me by one of its >> long-time proponents) is to have the performance characteristics of a >> release build (so no extra checks that affect performance or timing), >> but provide additional tools and data (printers, names, &etc) that we >> want to exclude from a release build for reasons of saving space or >> whatever. There's certainly lots of confusion around it though. > > Ultimately it's GC team call, but counters are extensively used in > optimized build. It this respect, it's perfectly fine to expose > add_obj_count and add_obj_bytes in optimized build. Same feeling here, but I'm fine with both versions. Not exactly sure if log_develop_debug is actually available in optimized builds, if not, then of course wrapping these into extra asserts makes more sense. Thanks, Thomas From igor.ignatyev at oracle.com Thu Aug 20 17:16:31 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 20 Aug 2020 10:16:31 -0700 Subject: RFR(T) : 8252005 : narrow disabling of allowSmartActionArgs in vmTestbase In-Reply-To: <17a8369e-5f38-ebab-974b-28e083378aa2@oracle.com> References: <4E6FECE6-9103-46ED-84B2-79DBA0123ED9@oracle.com> <17a8369e-5f38-ebab-974b-28e083378aa2@oracle.com> Message-ID: Hi Serguei, thanks for your review. I've decided to slightly modify the patch and use the ids of subtasks in TEST.properties files (instead of main bug id) in order to avoid possible confusion in the future: - incremental: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.0-1/index.html - whole: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.01/index.html could you please re-review it? Thanks, -- Igor > On Aug 19, 2020, at 4:22 PM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > This looks reasonable. > > Thanks, > Serguei > > > On 8/18/20 16:42, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ >>> 0 lines changed: 0 ins; 0 del; 0 mod; >> Hi all, >> >> could you please review this trivial (and apparently empty) patch which sets allowSmartActionArgs to false only in subdirectories of vmTestbase which currently use PropertyResolvingWrapper? >> >> (it's hard to tell from webrev or patch, but test/hotspot/jtreg/vmTestbase/TEST.properties is effectively removed) >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252005 >> >> Thanks, >> -- Igor >> >> > From igor.ignatyev at oracle.com Thu Aug 20 18:18:19 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 20 Aug 2020 11:18:19 -0700 Subject: RFR(T) : 8252005 : narrow disabling of allowSmartActionArgs in vmTestbase In-Reply-To: <8eb1187f-8030-2adf-b20d-d289bfa35198@oracle.com> References: <4E6FECE6-9103-46ED-84B2-79DBA0123ED9@oracle.com> <17a8369e-5f38-ebab-974b-28e083378aa2@oracle.com> <8eb1187f-8030-2adf-b20d-d289bfa35198@oracle.com> Message-ID: <3CB6B3FF-458B-4B76-872B-46A6D30B7A33@oracle.com> thanks Serguei, pushed. -- Igor > On Aug 20, 2020, at 10:55 AM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > Still looks good to me. > The webrev is veeeeery slow. > > Thanks, > Serguei > > > On 8/20/20 10:16, Igor Ignatyev wrote: >> Hi Serguei, >> >> thanks for your review. I've decided to slightly modify the patch and use the ids of subtasks in TEST.properties files (instead of main bug id) in order to avoid possible confusion in the future: >> - incremental: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.0-1/index.html >> - whole: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.01/index.html >> >> could you please re-review it? >> >> Thanks, >> -- Igor >> >>> On Aug 19, 2020, at 4:22 PM, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Igor, >>> >>> This looks reasonable. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 8/18/20 16:42, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ >>>>> 0 lines changed: 0 ins; 0 del; 0 mod; >>>> Hi all, >>>> >>>> could you please review this trivial (and apparently empty) patch which sets allowSmartActionArgs to false only in subdirectories of vmTestbase which currently use PropertyResolvingWrapper? >>>> >>>> (it's hard to tell from webrev or patch, but test/hotspot/jtreg/vmTestbase/TEST.properties is effectively removed) >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8252005/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252005 >>>> >>>> Thanks, >>>> -- Igor >>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Thu Aug 20 19:17:35 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Aug 2020 12:17:35 -0700 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <6aa79c90-3575-2858-c9b3-86e43dccd264@oracle.com> On 8/20/20 1:57 AM, Kim Barrett wrote: >> On Aug 19, 2020, at 10:00 AM, Christian Hagedorn wrote: >> >> Hi >> >> Please review the following small patch which fixes the broken optimized build: >> https://bugs.openjdk.java.net/browse/JDK-8252037 >> http://cr.openjdk.java.net/~chagedorn/8252037/webrev.00/ >> >> There are actually two build issues as shown in the bug description. >> >> Thank you! >> >> Best regards, >> Christian > > I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the > bug here is that these counters are being conditionally printed under PRODUCT, but should > be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an > optimized build in a while. > > [1] Quoting myself from a different recent review thread: > The purpose of "optimized" builds (as explained to me by one of its > long-time proponents) is to have the performance characteristics of a > release build (so no extra checks that affect performance or timing), > but provide additional tools and data (printers, names, &etc) that we > want to exclude from a release build for reasons of saving space or > whatever. There's certainly lots of confusion around it though I am still planning (when have a time) to work on: https://bugs.openjdk.java.net/browse/JDK-8202283 Vladimir K From kim.barrett at oracle.com Thu Aug 20 23:21:34 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 20 Aug 2020 19:21:34 -0400 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: <28aa2956-6fbc-f386-575a-596b56e39878@oracle.com> References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> <069e495e-c49d-8bfa-b437-5f20b40ba195@oracle.com> <28aa2956-6fbc-f386-575a-596b56e39878@oracle.com> Message-ID: > On Aug 20, 2020, at 7:48 AM, Vladimir Ivanov wrote: > > >>> [1] Quoting myself from a different recent review thread: >>> The purpose of "optimized" builds (as explained to me by one of its >>> long-time proponents) is to have the performance characteristics of a >>> release build (so no extra checks that affect performance or timing), >>> but provide additional tools and data (printers, names, &etc) that we >>> want to exclude from a release build for reasons of saving space or >>> whatever. There's certainly lots of confusion around it though. >> It's been a long time, low-priority issue to try and disentangle the bunch of "tweaks" that optimized builds bring, so they can be turned on and off individually. This would allow us to scrap optimized builds, which often bit-rot since they are seldom used. Unfortunately, the low priority of this means that no progress at all has been made for I think several years. :-( There is a JBS issue somewhere which outlines what kind of work is needed. > > This thread is probably not the best place to discuss it, but I don't see why wrapping the code and expose it as optional JVM feature will help avoid bit-rot. > > It can improve the code itself (choosing between "#ifdef ASSERT" and "#ifndef PRODUCT" is error-prone), but it won't make it built more frequently by itself. > > IMO the root cause is that optimized configuration is not built as part of any regular testing. And irrespective of how the code is shaped, it's required step to avoid bit-rot. The bug Magnus is looking for is JDK-8183287. But I agree that splitting the various pieces up into separately conditionally compiled chunks under their own specific control macros doesn?t fix the bit rot problem. If anything, it makes it worse. We could avoid bit rot in the optimized builds by just adding a build for it to the CI. Having N separate macros just means you need to turn them all on or all off (at least), and if you are actually paranoid about it you need to do all combinations thereof (yeah right, that?s not going to happen). From kim.barrett at oracle.com Thu Aug 20 23:57:10 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 20 Aug 2020 19:57:10 -0400 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> Message-ID: <5BE560EB-8FC4-401C-9E6D-FE9559EDE4EC@oracle.com> > On Aug 20, 2020, at 7:38 AM, Vladimir Ivanov wrote: > > >> I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the >> bug here is that these counters are being conditionally printed under PRODUCT, but should >> be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an >> optimized build in a while. >> [1] Quoting myself from a different recent review thread: >> The purpose of "optimized" builds (as explained to me by one of its >> long-time proponents) is to have the performance characteristics of a >> release build (so no extra checks that affect performance or timing), >> but provide additional tools and data (printers, names, &etc) that we >> want to exclude from a release build for reasons of saving space or >> whatever. There's certainly lots of confusion around it though. > > Ultimately it's GC team call, but counters are extensively used in optimized build. It this respect, it's perfectly fine to expose add_obj_count and add_obj_bytes in optimized build. > > Best regards, > Vladimir Ivanov As a non-user of optimized builds, I don?t have any vested interest in this question one way or the other. If people who do use it are okay with, or even prefer having these counters in such builds, I?m not going to object. But I think it makes the distinguishing characteristics of an optimized build and how to categorize and conditionalize bits of code even harder and more confusing than it already is. From Divino.Cesar at microsoft.com Sat Aug 22 20:06:49 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Sat, 22 Aug 2020 20:06:49 +0000 Subject: RFR(XS): 8011969 - scale for the "Time" column in -class in jstat_options should be seconds Message-ID: Hi there, could you please review the trivial patch below for this bug: https://bugs.openjdk.java.net/browse/JDK-8011969 Thanks, Cesar ------------ diff a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options --- a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options +++ b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options @@ -68,11 +68,11 @@ format "0.0" } column { header "^Time^" /* Accumulated time for class loading */ data sun.cls.time/sun.os.hrt.frequency - scale raw + scale sec align right width 10 format "0.00" } } From christian.hagedorn at oracle.com Mon Aug 24 08:08:15 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 24 Aug 2020 10:08:15 +0200 Subject: [16] RFR(XS): 8252037: Optimized build is broken In-Reply-To: <5BE560EB-8FC4-401C-9E6D-FE9559EDE4EC@oracle.com> References: <8af0eba9-31ca-91de-a271-fb16152da5e8@oracle.com> <5BE560EB-8FC4-401C-9E6D-FE9559EDE4EC@oracle.com> Message-ID: <1faaaada-ec7c-a8a8-edf5-108baf3dbc60@oracle.com> On 21.08.20 01:57, Kim Barrett wrote: >> On Aug 20, 2020, at 7:38 AM, Vladimir Ivanov wrote: >> >> >>> I think the changes to parallelgc are contrary to the intent of the optimized build [1]. I think the >>> bug here is that these counters are being conditionally printed under PRODUCT, but should >>> be printed under ASSERT. That is, 8232686 wasn?t quite right. I guess nobody has done an >>> optimized build in a while. >>> [1] Quoting myself from a different recent review thread: >>> The purpose of "optimized" builds (as explained to me by one of its >>> long-time proponents) is to have the performance characteristics of a >>> release build (so no extra checks that affect performance or timing), >>> but provide additional tools and data (printers, names, &etc) that we >>> want to exclude from a release build for reasons of saving space or >>> whatever. There's certainly lots of confusion around it though. >> >> Ultimately it's GC team call, but counters are extensively used in optimized build. It this respect, it's perfectly fine to expose add_obj_count and add_obj_bytes in optimized build. >> >> Best regards, >> Vladimir Ivanov > > As a non-user of optimized builds, I don?t have any vested interest in this > question one way or the other. If people who do use it are okay with, or even > prefer having these counters in such builds, I?m not going to object. But I > think it makes the distinguishing characteristics of an optimized build and how > to categorize and conditionalize bits of code even harder and more confusing > than it already is. Thanks to all for sharing their views. It seems that all are fine with both versions. Since the counters were originally meant to be available only in non-optimized builds with ASSERT and due to the reasons stated above I will go with the second version to exclude the introduced logging of JDK-8232686 in optimized builds: http://cr.openjdk.java.net/~chagedorn/8252037/webrev.01/ Best regards, Christian From volker.simonis at gmail.com Mon Aug 24 13:58:18 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 24 Aug 2020 15:58:18 +0200 Subject: http://cr.openjdk.java.net/ seems to be down Message-ID: Hi, I can't access http://cr.openjdk.java.net/ any more. I always get a "The connection to the server was reset while the page was loading" error. It seems that only the web-server is down because I can still sftp into cr.openjdk.java.net. Regards, Volker From tim.bell at oracle.com Mon Aug 24 15:01:20 2020 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 24 Aug 2020 08:01:20 -0700 Subject: http://cr.openjdk.java.net/ seems to be down In-Reply-To: References: Message-ID: <7fec5943-d86f-f0ec-a8a7-3d68b49c4aea@oracle.com> On 2020-08-24 06:58, Volker Simonis wrote: > I can't access http://cr.openjdk.java.net/ any more. I always get a > "The connection to the server was reset while the page was loading" > error. I can confirm that the server hosting http://openjdk.java.net, cr.openjdk.java.net, hg.openjdk.java.net, http://jdk.java.net, is very slow at best. Many things I try to do are timing out. > It seems that only the web-server is down because I can still sftp > into cr.openjdk.java.net. I reported an outage. I am escalating with the datacenter operations team. Tim From volker.simonis at gmail.com Mon Aug 24 15:12:39 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 24 Aug 2020 17:12:39 +0200 Subject: http://cr.openjdk.java.net/ seems to be down In-Reply-To: <7fec5943-d86f-f0ec-a8a7-3d68b49c4aea@oracle.com> References: <7fec5943-d86f-f0ec-a8a7-3d68b49c4aea@oracle.com> Message-ID: Thanks for the confirmation Tim. I just got a request through to http://openjdk.java.net but it took more than 30 minutes. And I've just noticed that https://hg.openjdk.java.net seems to be affected as well, so it might be good to add that to the escalation as well. Thanks one more time and best regards, Volker On Mon, Aug 24, 2020 at 5:03 PM Tim Bell wrote: > > On 2020-08-24 06:58, Volker Simonis wrote: > > > I can't access http://cr.openjdk.java.net/ any more. I always get a > > "The connection to the server was reset while the page was loading" > > error. > > I can confirm that the server hosting http://openjdk.java.net, > cr.openjdk.java.net, hg.openjdk.java.net, http://jdk.java.net, is very > slow at best. Many things I try to do are timing out. > > > It seems that only the web-server is down because I can still sftp > > into cr.openjdk.java.net. > > I reported an outage. I am escalating with the datacenter operations team. > > Tim From akozlov at azul.com Tue Aug 25 12:46:06 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 25 Aug 2020 15:46:06 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: Hi Andrew, On 19.08.2020 20:03, Andrew Haley wrote: >> Compared to the current patch, I don't think such template would be less >> error-prone or more maintainable. I would stick to the current version. > > OK. I rather like the template version: it's clear to me what the > intention is. But I agree it's marginal. > Does this count for the positive review? I assume concerns from you[1] and Bernhard[2] are resolved. And no more had followed. I would ask a colleague to sponsor this to jdk/jdk then. [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042733.html [2] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042731.html From aph at redhat.com Tue Aug 25 15:47:39 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 16:47:39 +0100 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: <00cc6c76-feaf-57eb-f985-71e2aa03f1ba@redhat.com> On 25/08/2020 13:46, Anton Kozlov wrote: > Hi Andrew, > > On 19.08.2020 20:03, Andrew Haley wrote: >>> Compared to the current patch, I don't think such template would be less >>> error-prone or more maintainable. I would stick to the current version. >> >> OK. I rather like the template version: it's clear to me what the >> intention is. But I agree it's marginal. >> > > Does this count for the positive review? I assume concerns from you[1] and > Bernhard[2] are resolved. And no more had followed. I would ask a colleague to > sponsor this to jdk/jdk then. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042733.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042731.html OK. I'm sorry I wasn't clear enough. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Tue Aug 25 21:54:19 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Aug 2020 14:54:19 -0700 Subject: [16] URGENT RFR(T) 8252331: JDK-8252058 is causing failures in Tier1 Message-ID: http://cr.openjdk.java.net/~kvn/8252331/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8252331 Added Graal changes [1] which were missing in 8252058 push [2]. Tested: hs-tier1 Thanks, Vladimir [1] http://cr.openjdk.java.net/~yzheng/8252058/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java.udiff.html [2] https://hg.openjdk.java.net/jdk/jdk/rev/1b2c88dbb4b3 From daniel.daugherty at oracle.com Tue Aug 25 21:56:51 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Aug 2020 17:56:51 -0400 Subject: [16] URGENT RFR(T) 8252331: JDK-8252058 is causing failures in Tier1 In-Reply-To: References: Message-ID: On 8/25/20 5:54 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8252331/webrev.00/ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ??? The changes that you added in your webrev match the changes from ??? yzheng's webrev. Thumbs up. Dan > https://bugs.openjdk.java.net/browse/JDK-8252331 > > Added Graal changes [1] which were missing in 8252058 push [2]. > > Tested: hs-tier1 > > Thanks, > Vladimir > > [1] > http://cr.openjdk.java.net/~yzheng/8252058/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java.udiff.html > > [2] https://hg.openjdk.java.net/jdk/jdk/rev/1b2c88dbb4b3 From vladimir.kozlov at oracle.com Tue Aug 25 21:59:03 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Aug 2020 14:59:03 -0700 Subject: [16] URGENT RFR(T) 8252331: JDK-8252058 is causing failures in Tier1 In-Reply-To: References: Message-ID: Thank you, Dan Vladimir K On 8/25/20 2:56 PM, Daniel D. Daugherty wrote: > On 8/25/20 5:54 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8252331/webrev.00/ > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > ??? The changes that you added in your webrev match the changes from > ??? yzheng's webrev. > > Thumbs up. > > Dan > > > >> https://bugs.openjdk.java.net/browse/JDK-8252331 >> >> Added Graal changes [1] which were missing in 8252058 push [2]. >> >> Tested: hs-tier1 >> >> Thanks, >> Vladimir >> >> [1] >> http://cr.openjdk.java.net/~yzheng/8252058/webrev.00/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java.udiff.html >> >> >> [2] https://hg.openjdk.java.net/jdk/jdk/rev/1b2c88dbb4b3 > From stefan.karlsson at oracle.com Wed Aug 26 11:57:48 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 26 Aug 2020 13:57:48 +0200 Subject: RFR: 8252368 : Undo JDK-8245002: Windows GDI functions don't support NUMA interleaving In-Reply-To: <7eccbe79-232b-a392-f89d-cdba9fb455a4@oracle.com> References: <7eccbe79-232b-a392-f89d-cdba9fb455a4@oracle.com> Message-ID: This was intended to go to hotspot-dev. Please review on that list. BCC:ing hotspot-gc-dev. On 2020-08-26 13:53, Stefan Karlsson wrote: > Hi all, > > Please review this patch to re-enable NUMA interleaving on Windows. > > https://cr.openjdk.java.net/~stefank/8252368/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252368 > > In JDK 15 we put in code that turns off NUMA interleaving if it is > detected that Windows GDI functions don't work with split memory > reservations. Later in JDK 16, and JDK 15.0.1, the code that uses GDI > was rewritten to have a fallback mechanism for these kinds of problems > (JDK-8240654). Because of that we don't need the workaround to turn off > NUMA interleaving anymore. > > We also pushed a similar workaround patch to turn off large pages > (JDK-8245000). That is dealt with in a separate RFR (JDK-8252367). This > patch builds upon the changes in JDK-8252367. > > I tested locally that the reproducer in JDK-8245000 doesn't reproduce > with the proposed patch. I also tested that also reverting the patch in > JDK-8240654 causes reproducer to reproduce again. > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Aug 26 11:57:45 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 26 Aug 2020 13:57:45 +0200 Subject: RFR: 8252367: Undo JDK-8245000: Windows GDI functions don't support large pages In-Reply-To: <086df9c2-9822-35da-c574-076fe9c35ceb@oracle.com> References: <086df9c2-9822-35da-c574-076fe9c35ceb@oracle.com> Message-ID: <011ac85f-548e-ab22-7c6d-d4d9df835359@oracle.com> This was intended to go to hotspot-dev. Please review on that list. BCC:ing hotspot-gc-dev. On 2020-08-26 13:52, Stefan Karlsson wrote: > Hi all, > > Please review this patch to re-enable large pages on Windows. > > https://cr.openjdk.java.net/~stefank/8252367/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252367 > > In JDK 15 we put in code that turns off large pages if it is detected > that Windows GDI functions don't work with large pages. Later in JDK 16, > and JDK 15.0.1, the code that uses GDI was rewritten to have a fallback > mechanism for these kinds of problems (JDK-8240654). Because of that we > don't need the workaround to turn off large pages anymore. > > We also pushed a similar workaround patch to turn off NUMA interleaving > (JDK-8245002). That will be dealt with in a separate RFR (JDK-8252368). > > I tested locally that the reproducer in JDK-8245000 doesn't reproduce > with the proposed patch. I also tested that also reverting the patch in > JDK-8240654 causes reproducer to reproduce again. > > Thanks, > StefanK From erik.osterlund at oracle.com Wed Aug 26 15:42:47 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 26 Aug 2020 17:42:47 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: Message-ID: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> Hi Kim, I have one comment on this. IMO using value or type based SFINAE is mostly a matter of preference. Either you prefer passing in trait types, or you prefer passing in constexpr booleans. The constexpr boolean approach seems to be strictly more useful IMO, because you can pass in evaluated constexpr functions, which is simply not possible in type based SFINAE. I have for example a situation where I have VM_Version support for a feature being returned in a constexpr function, that I can use to SFINAE away platform code on unsupported platforms (actual use case for me). Therefore, instead of having both EnableIfX and EnableIfT, I wonder if we could just stick to one convention instead, and say we pass in booleans, not types wrapping booleans. That way, there will never be any question as to which convention is being used or which one you should use - we use only one, and simply convert types to booleans before passing in to EnableIf. And then we don't need to have multiple EnableIf macros to differentiate the two cases. We just stick to one by convention and say this is the way we do things. Today we do not to my knowledge use any type SFINAE in HotSpot, it's all value based (the parameter to EnableIf is a bool, not a type). So it would further more seem that is the convention we already have today, and I think is the convention we want to keep on using, especially due to constexpr making that choice strictly more useful. So basically, my feedback is that I think you can safely remove EnableIfT and rename EnableIfX to EnableIf instead. What do you think? Thanks, /Erik On 2020-08-07 10:33, Kim Barrett wrote: > Please review this change which adds some utility alias templates for > function template SFINAE via additional non-type template parameters with > default values. These aliases can also be used for class template SFINAE > with a small change to current usage. > > With C++98/03 there are two ways to use enable_if with function templates: > > (1) As the return type > (2) As an extra parameter > > Both are syntactically messy, polluting the function signature. > > C++11 adds a third way, using an extra anonymous non-type template parameter > with a default value, i.e. > > // This overload is only considered when T is an integral type. > template::value, int> = 0> > void foo(T x) { ... } > > There's still a lot of syntactic noise in that, but we can substantially > reduce the noise using alias templates. With the proposed utilities, that > can be written as > > // This overload is only considered when T is an integral type. > template> = 0> > void foo(T x) { ... } > > The trailing " = 0" is a small remaining syntactic annoyance. That can't be > eliminated without the use of macros though. While I like macros, this > didn't seem to me to rise to the level of being worth using them. > > There are four new aliases: > > template EnableIfX; // int if V, else error. > template EnableIfT; // int if T::value, else error. > template EnableIfAnd; // int if Conjunction::value, else error. > template EnableIfOr; // int if Disjunction::value, else error. > > I'm open to bikeshedding on the names of EnableIfX and EnableIfT. > > (I'm disappointed that there's even a need for the distinction between > EnableIfX and EnableIfT. A macro can completely hide that distinction > (along with the conventional " = 0" default value if desired). > Unfortunately, the implementation of such a macro foundered on MSVC bugs > that I was unable to work around. To be fair, my preferred implementation > also ICE'd gcc.) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8251274 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8251274/open.00/ > > Testing: > tier1, along with conversion of some existing code to use the new mechanism. > From luhenry at microsoft.com Wed Aug 26 20:39:59 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Wed, 26 Aug 2020 20:39:59 +0000 Subject: Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> References: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Message-ID: Hi Anton, As Monica is on vacation, I just wanted to give a quick update on where we are standing. As of today, we have most of hotspot:tier1 and jdk:tier1 passing. The main remaining issues are around calling convention from the compiler into native (we already fixed it from the interpreter) and deprecated APIs in 11.0.0 (used in AWT, for example). We are not running into any major issue with W^X, and we have come up with a systematic approach that requires few modifications. On the deprecated APIs, we can easily dismiss the warnings with -Wno-deprecated-declarations, but that is not a long term fix. We'd love to have a chat with you to figure out how you would like to share learnings and join efforts. I'll contact you offline with some time proposals. Thank you, Ludovic -----Original Message----- From: hotspot-dev On Behalf Of Anton Kozlov Sent: Thursday, August 13, 2020 6:04 AM To: Monica Beckwith Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Subject: Re: Collaboration proposal: Draft JEP MacOS/AArch64 Port Hello Monica, Thank you for your proposal. It was a bit unexpected :) We would be happy to collaborate! Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK community) will need a project or repo for integration. But having win/aarch64 integrated, it may happen that mac/aarch64 support will be just a series of considerably isolated changes. An example is "JDK-8250876: Fix issues with cross-compile on macos" [1]. If all changes will be such self-containing, they may be reviewed and integrated one-by-one. Probably we won't need a project. I think this work is blocked by the JEP for the new platform support. I'll start a discussion email thread for that really soon. I hope we would be able to collaborate in all of the areas. I expect us to get soon to the point when we can start reviewing changes made for win/aarch64 and evaluate how do they fit mac/aarch64. Thanks, Anton [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=etFFyw9zye9g5gGgRY%2BB%2FCsspLo0TZ8Ct0dTvB0aa98%3D&reserved=0 On 11.08.2020 21:15, Monica Beckwith wrote: > Hello everyone,? > > It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? > > . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? > . Testing (all?regression,?functional, integration?and performance?tests)? > . Integration to?jdk/jdk?(tip)? > > Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? > > If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. > > We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? > > This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? > > Thanks,? > Monica > > [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fjeps%2F8251280&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=oCZSZXoU9sDUpfyr4GXzxhrU0YrMFjAzTLgbcD1BNtc%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fprograms%2Funiversal%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=Taczc6541YW4mVDkkCzg4XLprCJMOgSi6I4oxtWhJW4%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FHotSpot%2FStyleGuide&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=WLKmlWbb4oPkA7hN4Vz%2FE%2Ba6u52l7enipOvU0Gb3IgA%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=aW1A%2BifN9I0fIcyHj7vGZFgvOI83h5t2ErlAu3u4z6M%3D&reserved=0 > From igor.ignatyev at oracle.com Wed Aug 26 23:59:22 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 26 Aug 2020 16:59:22 -0700 Subject: RFR(T) : 8252401 : Introduce Utils.TEST_NATIVE_PATH Message-ID: <8E0C4E48-B435-4734-A86B-2C6745104BF7@oracle.com> http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 > 6 lines changed: 5 ins; 0 del; 1 mod; Hi all, could you please review this trivial patch which adds j.t.l.Utils.TEST_NATIVE_PATH static field to store the value of test.nativepath system property? JBS: https://bugs.openjdk.java.net/browse/JDK-8252401 webrev: http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 Thanks, -- Igor From igor.ignatyev at oracle.com Wed Aug 26 23:59:23 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 26 Aug 2020 16:59:23 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java Message-ID: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 > 287 lines changed: 60 ins; 200 del; 27 mod; Hi all, could you please review the patch which removes shell script from alloc001 test? there are two small difference comparing to the original test: - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 [1] https://bugs.openjdk.java.net/browse/JDK-8252401 [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 Thanks, -- Igor From david.holmes at oracle.com Thu Aug 27 05:03:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Aug 2020 15:03:35 +1000 Subject: RFR(XS): 8011969 - scale for the "Time" column in -class in jstat_options should be seconds In-Reply-To: References: Message-ID: Hi Cesar, Please take this to the serviceability-dev list for review. Thanks, David On 23/08/2020 6:06 am, Cesar Soares Lucas wrote: > Hi there, > > could you please review the trivial patch below for this bug: https://bugs.openjdk.java.net/browse/JDK-8011969 > > > Thanks, > Cesar > > ------------ > > > diff a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > --- a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > +++ b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > @@ -68,11 +68,11 @@ > format "0.0" > } > column { > header "^Time^" /* Accumulated time for class loading */ > data sun.cls.time/sun.os.hrt.frequency > - scale raw > + scale sec > align right > width 10 > format "0.00" > } > } > > From Divino.Cesar at microsoft.com Thu Aug 27 05:13:46 2020 From: Divino.Cesar at microsoft.com (Cesar Soares Lucas) Date: Thu, 27 Aug 2020 05:13:46 +0000 Subject: RFR(XS): 8011969 - scale for the "Time" column in -class in jstat_options should be seconds In-Reply-To: References: , Message-ID: I'll do that. Thanks David. ________________________________ From: David Holmes Sent: August 26, 2020 10:03 PM To: Cesar Soares Lucas ; hotspot-dev developers Subject: Re: RFR(XS): 8011969 - scale for the "Time" column in -class in jstat_options should be seconds Hi Cesar, Please take this to the serviceability-dev list for review. Thanks, David On 23/08/2020 6:06 am, Cesar Soares Lucas wrote: > Hi there, > > could you please review the trivial patch below for this bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8011969&data=02%7C01%7CDivino.Cesar%40microsoft.com%7C655db23e3a0040ba016008d84a46930b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637341014257318092&sdata=Hq8%2BuaC7ryNFyecKUoybEBygkIEPvN9u%2BcKX1Ol0N4s%3D&reserved=0 > > > Thanks, > Cesar > > ------------ > > > diff a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > --- a/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > +++ b/src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > @@ -68,11 +68,11 @@ > format "0.0" > } > column { > header "^Time^" /* Accumulated time for class loading */ > data sun.cls.time/sun.os.hrt.frequency > - scale raw > + scale sec > align right > width 10 > format "0.00" > } > } > > From kim.barrett at oracle.com Thu Aug 27 05:40:14 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Aug 2020 01:40:14 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> Message-ID: <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> > On Aug 26, 2020, at 11:42 AM, Erik ?sterlund wrote: > > Hi Kim, > > I have one comment on this. IMO using value or type based SFINAE is mostly a matter of preference. Either you prefer passing in trait types, or you prefer passing in constexpr booleans. The constexpr boolean approach seems to be strictly more useful IMO, because you can pass in evaluated constexpr functions, which is simply not possible in type based SFINAE. I have for example a situation where I have VM_Version support for a feature being returned in a constexpr function, that I can use to SFINAE away platform code on unsupported platforms (actual use case for me). IIt's easy to bounce back and forth using things like std::integral_constant. (One could even go the route of Boost.Hana for that sort of thing. But I don't think we are likely to be doing enough metaprogramming to make implementing that level of infrastructure worthwhile.) So I dispute the suggestion that one is more useful than the other. > Therefore, instead of having both EnableIfX and EnableIfT, I wonder if we could just stick to one convention instead, and say we pass in booleans, not types wrapping booleans. That way, there will never be any question as to which convention is being used or which one you should use - we use only one, and simply convert types to booleans before passing in to EnableIf. And then we don't need to have multiple EnableIf macros to differentiate the two cases. We just stick to one by convention and say this is the way we do things. Today we do not to my knowledge use any type SFINAE in HotSpot, it's all value based (the parameter to EnableIf is a bool, not a type). So it would further more seem that is the convention we already have today, and I think is the convention we want to keep on using, especially due to constexpr making that choice strictly more useful. We could do that. Indeed, the Standard only provides std::enable_if (and friends) that takes a bool condition. However, I think type-based SFINAE is common and likely to remain so because that's the form the type traits currently come in. (Though C++17 adds template variables for most or all of the trait types. We could perhaps provide our own until we can use C++17.) I find the frequent `::value` suffixes intrusive and annoying. (The alternative of constructing the trait type is perhaps less annoying, i.e. EnableIfX()>. Maybe that's good enough. It's also the same number of characters as the C++17 template variables, though less useful for additional calculations (unless going Boost.Hana style).) As I hinted in the RFR email, I tried to have one EnableIf-style API that handles an argument that can be either a trait type or a constexpr bool value. Something like template)> void foo(T x) { ... } template void foo(T1 x, T2 y) { ... } Unfortunately, all my attempts at that tripped over MSVC bugs. And my bug report was closed as won't fix. (gcc and clang worked fine for the most part. One of the many variants I tried (while failing to get past MSVC) ICE'd gcc, which I reported and was accepted as an ice-on-valid-code regression.) > So basically, my feedback is that I think you can safely remove EnableIfT and rename EnableIfX to EnableIf instead. Not while we still have (currently ~100) uses of our (perhaps legacy) EnableIf, which is significantly different. I'm not interested in developing or reviewing a change of all the existing EnableIf for function templates to use the new additional template parameter mechanism in one changeset. From akozlov at azul.com Thu Aug 27 08:17:10 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 27 Aug 2020 11:17:10 +0300 Subject: Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: References: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Message-ID: <74fb31b5-22fe-41eb-d04e-50b288b23eb6@azul.com> Hi! It seems we are in a similar state. Same problem with native_wrapper, e.g subsequent byte arguments are adjacent on stack[1]. So far we bailout when a-smaller-than-word-argument is allocated on stack (and use interpreted version). The problem is VMReg for stack slots does not able to encode stack places with bytes granularity. I think it is fine to allocate same (or none) stack VMReg for small arguments, but we have not tried that yet. I think we've come up with the same or similar systematic approaches. I'm not ready to say I have something that is correct by construction for W^X, but I feel I'm close. A few latest iterations mostly works but a few edge cases makes me re-think about invariants. Thanks, Anton [1] https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW4 On 26.08.2020 23:39, Ludovic Henry wrote: > Hi Anton, > > As Monica is on vacation, I just wanted to give a quick update on where we are standing. > > As of today, we have most of hotspot:tier1 and jdk:tier1 passing. The main remaining issues are around calling convention from the compiler into native (we already fixed it from the interpreter) and deprecated APIs in 11.0.0 (used in AWT, for example). We are not running into any major issue with W^X, and we have come up with a systematic approach that requires few modifications. On the deprecated APIs, we can easily dismiss the warnings with -Wno-deprecated-declarations, but that is not a long term fix. > > We'd love to have a chat with you to figure out how you would like to share learnings and join efforts. I'll contact you offline with some time proposals. > > Thank you, > Ludovic > > -----Original Message----- > From: hotspot-dev On Behalf Of Anton Kozlov > Sent: Thursday, August 13, 2020 6:04 AM > To: Monica Beckwith > Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > Subject: Re: Collaboration proposal: Draft JEP MacOS/AArch64 Port > > Hello Monica, > > Thank you for your proposal. It was a bit unexpected :) We would be happy to > collaborate! > > Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK > community) will need a project or repo for integration. But having win/aarch64 > integrated, it may happen that mac/aarch64 support will be just a series of > considerably isolated changes. An example is "JDK-8250876: Fix issues with > cross-compile on macos" [1]. If all changes will be such self-containing, they > may be reviewed and integrated one-by-one. Probably we won't need a project. > > I think this work is blocked by the JEP for the new platform support. I'll > start a discussion email thread for that really soon. > > I hope we would be able to collaborate in all of the areas. I expect us to get > soon to the point when we can start reviewing changes made for win/aarch64 and > evaluate how do they fit mac/aarch64. > > Thanks, > Anton > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=etFFyw9zye9g5gGgRY%2BB%2FCsspLo0TZ8Ct0dTvB0aa98%3D&reserved=0 > > On 11.08.2020 21:15, Monica Beckwith wrote: >> Hello everyone,? >> >> It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? >> >> . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? >> . Testing (all?regression,?functional, integration?and performance?tests)? >> . Integration to?jdk/jdk?(tip)? >> >> Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? >> >> If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. >> >> We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? >> >> This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? >> >> Thanks,? >> Monica >> >> [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fjeps%2F8251280&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=oCZSZXoU9sDUpfyr4GXzxhrU0YrMFjAzTLgbcD1BNtc%3D&reserved=0 >> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fprograms%2Funiversal%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=Taczc6541YW4mVDkkCzg4XLprCJMOgSi6I4oxtWhJW4%3D&reserved=0 >> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FHotSpot%2FStyleGuide&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=WLKmlWbb4oPkA7hN4Vz%2FE%2Ba6u52l7enipOvU0Gb3IgA%3D&reserved=0 >> [4] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=aW1A%2BifN9I0fIcyHj7vGZFgvOI83h5t2ErlAu3u4z6M%3D&reserved=0 >> From erik.osterlund at oracle.com Thu Aug 27 08:24:41 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 27 Aug 2020 10:24:41 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> Message-ID: Hi Kim, On 2020-08-27 07:40, Kim Barrett wrote: >> On Aug 26, 2020, at 11:42 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> I have one comment on this. IMO using value or type based SFINAE is mostly a matter of preference. Either you prefer passing in trait types, or you prefer passing in constexpr booleans. The constexpr boolean approach seems to be strictly more useful IMO, because you can pass in evaluated constexpr functions, which is simply not possible in type based SFINAE. I have for example a situation where I have VM_Version support for a feature being returned in a constexpr function, that I can use to SFINAE away platform code on unsupported platforms (actual use case for me). > IIt's easy to bounce back and forth using things like std::integral_constant. > (One could even go the route of Boost.Hana for that sort of thing. But I > don't think we are likely to be doing enough metaprogramming to make > implementing that level of infrastructure worthwhile.) So I dispute the > suggestion that one is more useful than the other. It is also easy to write ::value when passing in a type. BTW what I meant with one style being more "useful" than the other... what I really meant to say is that the value SFINAE is strictly more powerful than type SFINAE in expressiveness. Specifically, you can express all type SFINAE with value SFINAE by just appending "::value" to the type trait you pass in. Conversely, you can not express all useages of value SFINAE with type SFINAE, due to constexpr. This makes value SFINAE strictly more powerful in expressiveness. Unless you write the whole constexpr function body as a composition of type traits of course... which I hope we won't do... but we kind of actually do in some places as we didn't have constexpr available yet. So if we are to have a convention using only one of the two, value SFINAE is the more desirable alternative. >> Therefore, instead of having both EnableIfX and EnableIfT, I wonder if we could just stick to one convention instead, and say we pass in booleans, not types wrapping booleans. That way, there will never be any question as to which convention is being used or which one you should use - we use only one, and simply convert types to booleans before passing in to EnableIf. And then we don't need to have multiple EnableIf macros to differentiate the two cases. We just stick to one by convention and say this is the way we do things. Today we do not to my knowledge use any type SFINAE in HotSpot, it's all value based (the parameter to EnableIf is a bool, not a type). So it would further more seem that is the convention we already have today, and I think is the convention we want to keep on using, especially due to constexpr making that choice strictly more useful. > We could do that. Indeed, the Standard only provides std::enable_if (and > friends) that takes a bool condition. Right. And that is my preference too. > However, I think type-based SFINAE is common and likely to remain so because > that's the form the type traits currently come in. (Though C++17 adds > template variables for most or all of the trait types. We could perhaps > provide our own until we can use C++17.) > > I find the frequent `::value` suffixes intrusive and annoying. (The > alternative of constructing the trait type is perhaps less annoying, i.e. > EnableIfX()>. Maybe that's good enough. It's also the > same number of characters as the C++17 template variables, though less > useful for additional calculations (unless going Boost.Hana style).) Right. So on the one hand side you find it annoying to type "::value" when passing in a type trait. But on the other hand, having both EnableIfX and EnableIfT, and forcing readers, writers and reviewers to figure out which one is used or should be used, has the following also annoying properties: * There is no technical need for EnableIfT, so I don't see why we need the extra confusion about using EnableIfT vs EnableIfX. And I think SFINAE code does not necessarily need to become more confusing than it already is to readers in HotSpot. * Makes us not have a convention any more. Code will be written inconsistently sometimes randomly passing in a bool by some programmers, and with a type for other programmers, based on stylistic preferences alone, as opposed to different technical needs. I think that kind of stylistic choices only leads to a soup of different code styles and inconsistencies that didn't need to be there if we could just agree upon one convention instead. Such things tend to also introduce meaningless discussion points and hence stalls in review threads, where people argue that this or that style should be used due to different consistency vs style preference arguments and opinions. With a single convention, such debates are more easily shut down. * If we are suddenly allowing type SFINAE as well, purely because we think it stylistically looks better, then let's discuss style. I think having to write EnableIfX instead of EnableIf (or similarly ENABLE_IF_X instead of ENABLE_IF) is stylistically ugly. So if anything, having both type and value SFINAE, with one macro or trait for each variant, is not an obvious stylistic improvement to me. Quite the opposite in fact. > As I hinted in the RFR email, I tried to have one EnableIf-style API that > handles an argument that can be either a trait type or a constexpr bool > value. Something like > > template)> > void foo(T x) { ... } > > template > void foo(T1 x, T2 y) { ... } > > Unfortunately, all my attempts at that tripped over MSVC bugs. And my bug > report was closed as won't fix. > > (gcc and clang worked fine for the most part. One of the many variants I > tried (while failing to get past MSVC) ICE'd gcc, which I reported and was > accepted as an ice-on-valid-code regression.) Yeah. I think that having ENABLE_IF accept both types and values would be less confusing compared to having EnableIfX vs EnableIfT. But I think the even less confusing solution is to have an ENABLE_IF that only accepts bools, and make that the convention explicitly on the call site. So your example: ? template)> ? void foo(T x) { ... } would just have to adapt to the value SFINAE convention and do: ? template::value)> ? void foo(T x) { ... } Suddenly there is no need for ENABLE_IF to support both booleans and types, and there is a clear convention how to do SFINAE: with values. If the argument is that it is not pretty to have to write "::value", then I think the same stylistic comment can be said about having to append "T" to "EnableIf" to declare that you have this or that type of EnableIf that either will do the "::value" conversion for you internally or not. >> So basically, my feedback is that I think you can safely remove EnableIfT and rename EnableIfX to EnableIf instead. > Not while we still have (currently ~100) uses of our (perhaps legacy) > EnableIf, which is significantly different. I'm not interested in developing > or reviewing a change of all the existing EnableIf for function templates to > use the new additional template parameter mechanism in one changeset. While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway. Hope this all makes sense. Thanks, /Erik From kim.barrett at oracle.com Thu Aug 27 08:37:36 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Aug 2020 04:37:36 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> Message-ID: <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> > On Aug 27, 2020, at 4:24 AM, Erik ?sterlund wrote: > > While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway. I think there?s a misunderstanding here. The failed (because of MSVC bugs) approach of an ENABLE_IF macro that accepts either a type or a constexpr value is just not on the table. What?s being proposed has zero macros; it?s all alias templates. I considered having macros in order to eliminate the trailing ?= 0?, but that benefit didn?t seem to me to be worth (on it?s own) the issues that come with macros. (And remember that I like macros.) From erik.osterlund at oracle.com Thu Aug 27 09:10:30 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 27 Aug 2020 11:10:30 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> Message-ID: Hi Kim, On 2020-08-27 10:37, Kim Barrett wrote: >> On Aug 27, 2020, at 4:24 AM, Erik ?sterlund wrote: >> >> While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway. > I think there?s a misunderstanding here. > > The failed (because of MSVC bugs) approach of an ENABLE_IF macro that accepts either a type > or a constexpr value is just not on the table. > > What?s being proposed has zero macros; it?s all alias templates. > I considered having macros in order to eliminate the trailing ?= 0?, but that benefit didn?t seem to > me to be worth (on it?s own) the issues that come with macros. (And remember that I like macros.) Thank you for the clarification. So you said the approach of using ENABLE_IF macro that accepts either a type or constexpr value isn't on the table due to said compiler bugs. What was not and still is not clear to me is if the same bugs prevent an ENABLE_IF macro that accepts only a constexpr value. If that is also not on the table, then I see that we have a naming problem as long as the old legacy EnableIf is around. In other words - was the nature of the compiler problem that you can't use macros here at all, as opposed to being due to having to accept both types and values? I would appreciate clarification on that point in the problem domain before thinking further about the solution domain. Thanks, /Erik From aph at redhat.com Thu Aug 27 09:59:18 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Aug 2020 10:59:18 +0100 Subject: Add release barriers when allocating objects with concurrent collection Message-ID: 8165808 (Add release barriers when allocating objects with concurrent collection) added release barriers to object allocation paths. But it only added them in shared code, not in the fast-path code. I find a comment I added to AArch64 in 2013: void MacroAssembler::store_klass(Register dst, Register src) { + // FIXME: Should this be a store release? concurrent gcs assumes + // klass length is valid if klass field is not null. PPC doesn't have release barriers here either: void MacroAssembler::store_klass(Register dst_oop, Register klass, Register ck) { if (UseCompressedClassPointers) { encode_klass_not_null(ck, klass); stw(ck, oopDesc::klass_offset_in_bytes(), dst_oop); } else { std(klass, oopDesc::klass_offset_in_bytes(), dst_oop); } } So what's up? What should we be doing here? Surely if the slow path code needs the barriers, the fast path does too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Thu Aug 27 20:47:37 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Aug 2020 16:47:37 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> Message-ID: <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> > On Aug 27, 2020, at 5:10 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2020-08-27 10:37, Kim Barrett wrote: >>> On Aug 27, 2020, at 4:24 AM, Erik ?sterlund wrote: >>> >>> While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway. >> I think there?s a misunderstanding here. >> >> The failed (because of MSVC bugs) approach of an ENABLE_IF macro that accepts either a type >> or a constexpr value is just not on the table. >> >> What?s being proposed has zero macros; it?s all alias templates. >> I considered having macros in order to eliminate the trailing ?= 0?, but that benefit didn?t seem to >> me to be worth (on it?s own) the issues that come with macros. (And remember that I like macros.) > > Thank you for the clarification. > > So you said the approach of using ENABLE_IF macro that accepts either a type or constexpr value isn't on the table due to said compiler bugs. What was not and still is not clear to me is if the same bugs prevent an ENABLE_IF macro that accepts only a constexpr value. If that is also not on the table, then I see that we have a naming problem as long as the old legacy EnableIf is around. In other words - was the nature of the compiler problem that you can't use macros here at all, as opposed to being due to having to accept both types and values? > > I would appreciate clarification on that point in the problem domain before thinking further about the solution domain. > > Thanks, > /Erik That would work, as would a macro that takes a type. That is, both of these work. #define ENABLE_IF_T(...) EnableIfT<__VA_ARGS__> = 0 #define ENABLE_IF_X(...) EnableIfX<__VA_ARGS__> = 0 I didn't propose either of those because adding a macro just to eliminate the trailing " = 0" doesn't seem worthwhile. I proposed both EnableIfT and EnableIfX because I don't think either alone is worthwhile, though for different reasons. (Assume that if we only had one that the T/X suffix would eventually be eliminated.) Both of them are basically about reducing syntactic noise. EnableIfT alone doesn't deal well with expressions, as the syntax to convert a value into a type is non-trivial. And I agree that expressions need to be well supported. The alternative to value => type conversion for expressions would be to use std::enable_if_t directly, but I think frequent switching in nearby code between EnableIf[T] and std::enable_if_t is undesirable. EnableIfX alone doesn't, in my opinion, carry its weight; just use std::enable_if_t directly. EnableIfX is just template EnableIfX = std::enable_if_t; Usage would be (for example) template::value> = 0> void foo (T t) { ... } vs template::value, int> = 0> void foo (T t) { ... } I considered not proposing them at all. While I think together they provide enough to be worth having, I also think that's not blatantly clear and obvious. A single macro supporting both is much more compelling. If both were removed, I'm not sure what to do with EnableIfAnd/Or; retain in the proposal or retract the proposal entirely. From igor.ignatyev at oracle.com Fri Aug 28 02:39:38 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 27 Aug 2020 19:39:38 -0700 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument Message-ID: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ > 99 lines changed: 19 ins; 20 del; 60 mod; Hi all, could you please review the patch which unblocks the rest of 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? background from JBS: > jtreg splits command line by space to get the list of arguments and there is no way to prevent that (nor thru escaping, nor by adding quotes). currently, PropertyResolvingWrapper handles that and joins multiple arguments within double quotes into one argument before passing it to the actual test class. the only place where it's needed is in the tests which use nsk/share/ArgumentParser (or more precisely nsk.share.jpda.DebugeeArgumentHandler and nsk/share/jdb/JdbArgumentHandler). > > in preparation for PropertyResolvingWrapper removal, ArgumentParser should be updated to handle the "split" argument on its own. I've also taken the liberty to slightly clean up ArgumentParser. JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ testing: all the tests which use ArgumentParser (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 Thanks, -- Igor From david.holmes at oracle.com Fri Aug 28 04:09:13 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Aug 2020 14:09:13 +1000 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument In-Reply-To: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> References: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> Message-ID: Hi Igor, In case there may be a parsing error and the command-line is ill-formed, should you abort if you reach the end of the arg list without finding an even number of double-quotes? Or will parseArguments already handle that? Otherwise the changes seem good. Thanks, David ----- On 28/08/2020 12:39 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >> 99 lines changed: 19 ins; 20 del; 60 mod; > > Hi all, > > could you please review the patch which unblocks the rest of 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? > > background from JBS: >> jtreg splits command line by space to get the list of arguments and there is no way to prevent that (nor thru escaping, nor by adding quotes). currently, PropertyResolvingWrapper handles that and joins multiple arguments within double quotes into one argument before passing it to the actual test class. the only place where it's needed is in the tests which use nsk/share/ArgumentParser (or more precisely nsk.share.jpda.DebugeeArgumentHandler and nsk/share/jdb/JdbArgumentHandler). >> >> in preparation for PropertyResolvingWrapper removal, ArgumentParser should be updated to handle the "split" argument on its own. > > I've also taken the liberty to slightly clean up ArgumentParser. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 > webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ > testing: all the tests which use ArgumentParser (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 > > Thanks, > -- Igor > From serguei.spitsyn at oracle.com Fri Aug 28 07:39:03 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Aug 2020 00:39:03 -0700 Subject: RFR(T) : 8252401 : Introduce Utils.TEST_NATIVE_PATH In-Reply-To: <8E0C4E48-B435-4734-A86B-2C6745104BF7@oracle.com> References: <8E0C4E48-B435-4734-A86B-2C6745104BF7@oracle.com> Message-ID: Hi Igor, It looks good and trivial. Thanks, Serguei On 8/26/20 16:59, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >> 6 lines changed: 5 ins; 0 del; 1 mod; > Hi all, > > could you please review this trivial patch which adds j.t.l.Utils.TEST_NATIVE_PATH static field to store the value of test.nativepath system property? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252401 > webrev: http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 > > Thanks, > -- Igor From erik.osterlund at oracle.com Fri Aug 28 07:44:56 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 28 Aug 2020 09:44:56 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> Message-ID: Hi Kim, On 2020-08-27 22:47, Kim Barrett wrote: >> On Aug 27, 2020, at 5:10 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> On 2020-08-27 10:37, Kim Barrett wrote: >>>> On Aug 27, 2020, at 4:24 AM, Erik ?sterlund wrote: >>>> >>>> While I think having a legacy style that we are telling people not to use is unfortunate, I do understand that such a cleanup is a larger undertaking. So if the concern is that the identifier "EnableIf" is already taken today, then I think you can do what your previous example did: call the macro variant used inside of the template arguments ENABLE_IF instead, and have it take values only. Then we can transition away from using now "legacy" EnableIf gradually. And seeing as it is a macro, using capital letters is the natural name anyway. >>> I think there?s a misunderstanding here. >>> >>> The failed (because of MSVC bugs) approach of an ENABLE_IF macro that accepts either a type >>> or a constexpr value is just not on the table. >>> >>> What?s being proposed has zero macros; it?s all alias templates. >>> I considered having macros in order to eliminate the trailing ?= 0?, but that benefit didn?t seem to >>> me to be worth (on it?s own) the issues that come with macros. (And remember that I like macros.) >> Thank you for the clarification. >> >> So you said the approach of using ENABLE_IF macro that accepts either a type or constexpr value isn't on the table due to said compiler bugs. What was not and still is not clear to me is if the same bugs prevent an ENABLE_IF macro that accepts only a constexpr value. If that is also not on the table, then I see that we have a naming problem as long as the old legacy EnableIf is around. In other words - was the nature of the compiler problem that you can't use macros here at all, as opposed to being due to having to accept both types and values? >> >> I would appreciate clarification on that point in the problem domain before thinking further about the solution domain. >> >> Thanks, >> /Erik > That would work, as would a macro that takes a type. That is, both of > these work. > > #define ENABLE_IF_T(...) EnableIfT<__VA_ARGS__> = 0 > #define ENABLE_IF_X(...) EnableIfX<__VA_ARGS__> = 0 > > I didn't propose either of those because adding a macro just to eliminate > the trailing " = 0" doesn't seem worthwhile. I see. Yeah I can see how that might not feel worthwhile. Although in a way, I guess the macro would hide the implementation details of the enable if mechanism, that otherwise leak out to the enable if user. > I proposed both EnableIfT and EnableIfX because I don't think either alone > is worthwhile, though for different reasons. (Assume that if we only had one > that the T/X suffix would eventually be eliminated.) Both of them are > basically about reducing syntactic noise. > > EnableIfT alone doesn't deal well with expressions, as the syntax to convert > a value into a type is non-trivial. And I agree that expressions need to be > well supported. The alternative to value => type conversion for expressions > would be to use std::enable_if_t directly, but I think frequent switching in > nearby code between EnableIf[T] and std::enable_if_t is undesirable. > > EnableIfX alone doesn't, in my opinion, carry its weight; just use > std::enable_if_t directly. EnableIfX is just > > template EnableIfX = std::enable_if_t; > > Usage would be (for example) > > template::value> = 0> > void foo (T t) { ... } > > vs > > template::value, int> = 0> > void foo (T t) { ... } > > I considered not proposing them at all. While I think together they provide > enough to be worth having, I also think that's not blatantly clear and > obvious. A single macro supporting both is much more compelling. If both > were removed, I'm not sure what to do with EnableIfAnd/Or; retain in the > proposal or retract the proposal entirely. I once again understand that having just an alias type for std::enable_if_t that takes an int might not feel worth while. I can't believe I'm about to say this though, but what if you combine the two not worthwhile things into that macro... it just might become worthwhile combined (yes I think I am in favour of the macro while you are not - I don't know what is going on either!). So if we don't do anything, the template parameter SFINAE syntax would seemingly be: template::value, int> = 0> void foo (T t) { ... } And if we have an ENABLE_IF macro that takes values only (keeping to the convention we have to work with values only as discussed previously), it would be: template::value)> void foo (T t) { ... } Here, I think I would actually prefer using the macro that hides the implementation details how it works from the user, and in the API just focuses on only passing in the right condition. Also, not importantly, the identifier ENABLE_IF is not taken (while EnableIf is). That macro can also have some comments describing the trick at one point, which I think is quite useful on its own. I guess the macro itself would look like this: #define ENABLE_IF(...) std::enable_if_t<__VA_ARGS__ , int> = 0 So this value SFINAE only macro for doing SFINAE using a template parameter seems like something that we can actually do without relying on any compiler bugs being fixed or refactoring the world in HotSpot (yet). And I think it is more readable than the return type SFINAE we have today (that requires extra lines for the return type, and you have to scratch your head to figure out what the actual return type is). I would say that such a value SFINAE macro is worthwhile doing, IMO. I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa. What do you think? Thanks, /Erik From erik.osterlund at oracle.com Fri Aug 28 08:09:14 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 28 Aug 2020 10:09:14 +0200 Subject: Add release barriers when allocating objects with concurrent collection In-Reply-To: References: Message-ID: <0eb34a33-4b23-ae94-3db7-147b545c7e50@oracle.com> Hi Andrew, This is an excellent question. In fact, perhaps this should be better documented in the code. You should not need any fencing in the fast path, and the race indeed only happens for the slow path. If you allocate an object in a TLAB, then it will be allocated in memory that is not concurrently visited by any GC in HotSpot (eden for STW collectors, allocating pages for ZGC, something similar for Shenandoah I guess). And they are simply not traversed concurrently by the GC. So to the best of my knowledge, this code is really there only for huge allocations. Huge allocations may be done in fast paths when CollectedHeap::supports_inline_contig_alloc() is true. But it is not true for the collectors that poke said objects concurrently. Therefore, such objects will instead be allocated with a slow path call, which will perform the right release_store dance in the runtime, for such huge objects. These huge objects are not necessarily part of young gen, and may be traversed concurrently. So as other objects have at least the header initialized in young gen or equivalent (allocating) memory, they should not need any release_store when initializing the Klass header, to satisfy the GC. However, I'm not sure what happens if you share objects that have not finished running their constructor to e.g. a static field, and another Java thread racingly reads it and tries to make sense out of it. Feels like that might be a bit awkward... Thanks, /Erik On 2020-08-27 11:59, Andrew Haley wrote: > 8165808 (Add release barriers when allocating objects with concurrent > collection) added release barriers to object allocation paths. But it > only added them in shared code, not in the fast-path code. > > I find a comment I added to AArch64 in 2013: > > void MacroAssembler::store_klass(Register dst, Register src) { > + // FIXME: Should this be a store release? concurrent gcs assumes > + // klass length is valid if klass field is not null. > > PPC doesn't have release barriers here either: > > void MacroAssembler::store_klass(Register dst_oop, Register klass, Register ck) { > if (UseCompressedClassPointers) { > encode_klass_not_null(ck, klass); > stw(ck, oopDesc::klass_offset_in_bytes(), dst_oop); > } else { > std(klass, oopDesc::klass_offset_in_bytes(), dst_oop); > } > } > > So what's up? What should we be doing here? Surely if the slow path > code needs the barriers, the fast path does too. > From aph at redhat.com Fri Aug 28 15:24:45 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Aug 2020 16:24:45 +0100 Subject: Add release barriers when allocating objects with concurrent collection In-Reply-To: <0eb34a33-4b23-ae94-3db7-147b545c7e50@oracle.com> References: <0eb34a33-4b23-ae94-3db7-147b545c7e50@oracle.com> Message-ID: <8d9582e5-18c5-390e-d4a1-f97bff5bd6c1@redhat.com> On 28/08/2020 09:09, Erik ?sterlund wrote: > If you allocate an object in a TLAB, then it will be allocated in > memory that is not concurrently visited by any GC in HotSpot (eden > for STW collectors, allocating pages for ZGC, something similar for > Shenandoah I guess). And they are simply not traversed concurrently > by the GC. OK, I think. Every time I think that I understand how GCs work, something like this comes along to prove I don't. Let's say that the only reference to an object X in the heap is contained in an array in some thread's TLAB. I guess that X will be kept alive because its reference is in the SATB buffer, right? > However, I'm not sure what happens if you share objects that have > not finished running their constructor to e.g. a static field, and > another Java thread racingly reads it and tries to make sense out of > it. Feels like that might be a bit awkward... There's always a StoreStore barrier before any user code starts executing. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Fri Aug 28 15:55:51 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 28 Aug 2020 17:55:51 +0200 Subject: Add release barriers when allocating objects with concurrent collection In-Reply-To: <8d9582e5-18c5-390e-d4a1-f97bff5bd6c1@redhat.com> References: <0eb34a33-4b23-ae94-3db7-147b545c7e50@oracle.com> <8d9582e5-18c5-390e-d4a1-f97bff5bd6c1@redhat.com> Message-ID: <7d706b8e-e5ca-aea3-176a-232e631a0f90@oracle.com> Hi Andrew On 2020-08-28 17:24, Andrew Haley wrote: > On 28/08/2020 09:09, Erik ?sterlund wrote: > >> If you allocate an object in a TLAB, then it will be allocated in >> memory that is not concurrently visited by any GC in HotSpot (eden >> for STW collectors, allocating pages for ZGC, something similar for >> Shenandoah I guess). And they are simply not traversed concurrently >> by the GC. > OK, I think. Every time I think that I understand how GCs work, > something like this comes along to prove I don't. Let's say that the > only reference to an object X in the heap is contained in an array in > some thread's TLAB. I guess that X will be kept alive because its > reference is in the SATB buffer, right? It works a bit differently in every GC. But I think the common theme is that after you start concurrently marking at a snapshot in time, all new allocations from that point and onward, will not be considered for being GC:ed this cycle, and hence won't be visited. TLABs are retired, so that new TLABs are created in some new space that is not collected. If you manage to write a reference from the allocated object to a an object that is older than when concurrent GC started, then at the point you performed a write to this object, then either 1) The reference you are writing is a root, and the collector guarantees everything that ?? ? becomes a root is marked as it becomes a root (ZGC, C4). 2) Due to the reference being a root, it must have been reachable at the snapshot at the ?? ? beginning (SATB collectors - G1, Shenandoah with ShenandoahGCMode="satb"), or ???? been added to a SATB buffer when said link was broken. 3) At the point of writing said reference, the object is marked, or shaded "gray" in the ??? dijkstra tri-colour scheme (incremental update - CMS, Shenandoah with ShenandoahGCMode="iu") >> However, I'm not sure what happens if you share objects that have >> not finished running their constructor to e.g. a static field, and >> another Java thread racingly reads it and tries to make sense out of >> it. Feels like that might be a bit awkward... > There's always a StoreStore barrier before any user code starts > executing. Ah. That sounds promising. Thanks, /Erik From igor.ignatyev at oracle.com Fri Aug 28 17:29:16 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Aug 2020 10:29:16 -0700 Subject: RFR(T) : 8252401 : Introduce Utils.TEST_NATIVE_PATH In-Reply-To: References: <8E0C4E48-B435-4734-A86B-2C6745104BF7@oracle.com> Message-ID: thanks Serguei, pushed. -- Igor > On Aug 28, 2020, at 12:39 AM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > It looks good and trivial. > > Thanks, > Serguei > > > On 8/26/20 16:59, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >>> 6 lines changed: 5 ins; 0 del; 1 mod; >> Hi all, >> >> could you please review this trivial patch which adds j.t.l.Utils.TEST_NATIVE_PATH static field to store the value of test.nativepath system property? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252401 >> webrev: http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >> >> Thanks, >> -- Igor > From igor.ignatyev at oracle.com Fri Aug 28 18:18:54 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Aug 2020 11:18:54 -0700 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument In-Reply-To: References: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> Message-ID: <848EB368-B244-4376-91D0-770FF0141477@oracle.com> Hi David, good point, parseArguments (or rather checkOption) does indeed validate that passed option is valid and has a valid value, yet for many options all values are treated as valid, so ill-formed command lines like `-debugee.vmkeys="${test.vm.opts} ${test.java.opts} -transport.address=dynamic` won't be spotted by ArgumentParser and its sub-classes, and I'm afraid in some cases might change tests' behavior unnoticeably. thus I've decided to add the check that we always have even number of double quotes: > diff -r 83f273f313aa test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java > --- a/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Thu Aug 27 19:37:51 2020 -0700 > +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Fri Aug 28 11:16:24 2020 -0700 > @@ -156,6 +156,10 @@ > arg.append(" ").append(args[++i]); > doubleQuotes += numberOfDoubleQuotes(args[i]); > } > + if (doubleQuotes % 2 != 0) { > + throw new TestBug("command-line has odd number of double quotes:" + String.join(" ", args)); > + } > + > list.add(arg.toString()); > } > setRawArguments(list.toArray(String[]::new)); Thanks, -- Igor > On Aug 27, 2020, at 9:09 PM, David Holmes wrote: > > Hi Igor, > > In case there may be a parsing error and the command-line is ill-formed, should you abort if you reach the end of the arg list without finding an even number of double-quotes? Or will parseArguments already handle that? > > Otherwise the changes seem good. > > Thanks, > David > ----- > > On 28/08/2020 12:39 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>> 99 lines changed: 19 ins; 20 del; 60 mod; >> Hi all, >> could you please review the patch which unblocks the rest of 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? >> background from JBS: >>> jtreg splits command line by space to get the list of arguments and there is no way to prevent that (nor thru escaping, nor by adding quotes). currently, PropertyResolvingWrapper handles that and joins multiple arguments within double quotes into one argument before passing it to the actual test class. the only place where it's needed is in the tests which use nsk/share/ArgumentParser (or more precisely nsk.share.jpda.DebugeeArgumentHandler and nsk/share/jdb/JdbArgumentHandler). >>> >>> in preparation for PropertyResolvingWrapper removal, ArgumentParser should be updated to handle the "split" argument on its own. >> I've also taken the liberty to slightly clean up ArgumentParser. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 >> webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >> testing: all the tests which use ArgumentParser (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Fri Aug 28 19:32:45 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Aug 2020 12:32:45 -0700 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor Message-ID: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ > 118 lines changed: 32 ins; 36 del; 50 mod; Hi all, could you please review this small patch which updates StressOptions to adjust allocated time according to TIMEOUT_FACTOR? from JBS: > nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress time for testing in slow/stress configurations, e.g. Xcomp. the patch also includes small clean up and refactoring, such as removal of unused c-tor and using switch instead if-elif. webrev w/o these changes -- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ webrev: http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8252522 testing: vmTestbase tests (in progress) Thanks, -- Igor From kim.barrett at oracle.com Fri Aug 28 19:46:44 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 28 Aug 2020 15:46:44 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> Message-ID: > On Aug 28, 2020, at 3:44 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2020-08-27 22:47, Kim Barrett wrote: >> That would work, as would a macro that takes a type. That is, both of >> these work. >> >> #define ENABLE_IF_T(...) EnableIfT<__VA_ARGS__> = 0 >> #define ENABLE_IF_X(...) EnableIfX<__VA_ARGS__> = 0 >> >> I didn't propose either of those because adding a macro just to eliminate >> the trailing " = 0" doesn't seem worthwhile. > > I see. Yeah I can see how that might not feel worthwhile. Although in a way, > I guess the macro would hide the implementation details of the enable if mechanism, > that otherwise leak out to the enable if user. > >> I proposed both EnableIfT and EnableIfX because I don't think either alone >> is worthwhile, though for different reasons. (Assume that if we only had one >> that the T/X suffix would eventually be eliminated.) Both of them are >> basically about reducing syntactic noise. >> >> EnableIfT alone doesn't deal well with expressions, [?] >> >> EnableIfX alone doesn't, in my opinion, carry its weight; just use >> std::enable_if_t directly. [?] >> >> I considered not proposing them at all. While I think together they provide >> enough to be worth having, I also think that's not blatantly clear and >> obvious. A single macro supporting both is much more compelling. If both >> were removed, I'm not sure what to do with EnableIfAnd/Or; retain in the >> proposal or retract the proposal entirely. > > I once again understand that having just an alias type for std::enable_if_t > that takes an int might not feel worth while. > > I can't believe I'm about to say this though, but what if you combine the > two not worthwhile things into that macro... it just might become worthwhile > combined (yes I think I am in favour of the macro while you are not - I don't > know what is going on either!). What have you done with the real Erik? > So if we don't do anything, the template parameter SFINAE syntax would seemingly be: > > template::value, int> = 0> > void foo (T t) { ... } > > And if we have an ENABLE_IF macro that takes values only (keeping to the convention > we have to work with values only as discussed previously), it would be: > > template::value)> > void foo (T t) { ... } > > Here, I think I would actually prefer using the macro that hides the implementation > details how it works from the user, and in the API just focuses on only passing in > the right condition. Also, not importantly, the identifier ENABLE_IF is not taken > (while EnableIf is). That macro can also have some comments describing the trick > at one point, which I think is quite useful on its own. > > I guess the macro itself would look like this: > #define ENABLE_IF(...) std::enable_if_t<__VA_ARGS__ , int> = 0 The macro needs to be #define ENABLE_IF(...) std::enable_if_t<(__VA_ARGS__), int> = 0 Otherwise one gets a mess from `ENABLE_IF(sizeof(T) > 4)` for example; the angle bracket closes the template parameter list instead of being a greater than operator. > So this value SFINAE only macro for doing SFINAE using a template parameter seems like > something that we can actually do without relying on any compiler bugs being fixed or > refactoring the world in HotSpot (yet). And I think it is more readable than the return > type SFINAE we have today (that requires extra lines for the return type, and you have > to scratch your head to figure out what the actual return type is). I would say that > such a value SFINAE macro is worthwhile doing, IMO. This is the main point of all this, of course. As you know, I really dislike the C++98 function template SFINAE syntax. So much so that I'd rather delegate to class templates, as was done with the Atomic::*Impl classes. The new style enabled by this C++11 feature changes everything. So I'm highly motivated to reach some consensus on how we're going to use this new feature. I think that macro is okay. I would be even happier with it if we had variable templates for the type traits, a la C++17, so std::is_integral::value => std::is_integral_v We could add a suite of IsIntegralV &etc variable templates. Alternatively, I wonder how much trouble we might be taking on if we conditionally defined them with something like #if __cplusplus == 201402L namespace std { template constexpr bool is_integral_v = std::is_integral::value; ... } #endif // __cplusplus (Note that we can't get *exactly* the behavior of C++17 for these, since inline variables are a C++17 language feature. The difference is linkage, but I don't expect anyone to care whether `&IsIntegralV` in different translation units result in the same address.) > I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like > having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa. > > What do you think? I had code that used the combined type/value macro and was ready to move forward with that until I tried testing with Visual Studio (sigh!). I?d prefer being able to use the variable template forms of various traits, but could live without if need be. If we adopt this macro, I'm inclined to just drop the proposed EnableIfAnd<...> and EnableIfOr. I?ve not encountered that many uses for the Or case. The And case can be done with separate ENABLE_IF?s, and indeed there is a little bit of benefit to doing so, as the compiler may give more helpful error messages when trying to figure out why one of the cases failed. (Similar to why it?s better to split conjunctive asserts.) From igor.ignatyev at oracle.com Sat Aug 29 03:52:19 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Aug 2020 20:52:19 -0700 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") Message-ID: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 > 145 lines changed: 28 ins; 22 del; 95 mod; Hi all, could you please review this trivial clean up which replaces System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where appropriate? while updating these files, I've also cleaned them up a bit, removed unneeded imports, added/removed spaces, etc testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on {linux,windows,macos}-x64 JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 Thanks, -- Igor From david.holmes at oracle.com Mon Aug 31 01:59:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Aug 2020 11:59:45 +1000 Subject: Add release barriers when allocating objects with concurrent collection In-Reply-To: <7d706b8e-e5ca-aea3-176a-232e631a0f90@oracle.com> References: <0eb34a33-4b23-ae94-3db7-147b545c7e50@oracle.com> <8d9582e5-18c5-390e-d4a1-f97bff5bd6c1@redhat.com> <7d706b8e-e5ca-aea3-176a-232e631a0f90@oracle.com> Message-ID: <4e7b9d89-cad8-3b14-cbc8-6be8a76229a1@oracle.com> Just to be crystal clear on something ... On 29/08/2020 1:55 am, Erik ?sterlund wrote: > Hi Andrew > > On 2020-08-28 17:24, Andrew Haley wrote: >> On 28/08/2020 09:09, Erik ?sterlund wrote: >> >>> If you allocate an object in a TLAB, then it will be allocated in >>> memory that is not concurrently visited by any GC in HotSpot (eden >>> for STW collectors, allocating pages for ZGC, something similar for >>> Shenandoah I guess). And they are simply not traversed concurrently >>> by the GC. >> OK, I think. Every time I think that I understand how GCs work, >> something like this comes along to prove I don't. Let's say that the >> only reference to an object X in the heap is contained in an array in >> some thread's TLAB. I guess that X will be kept alive because its >> reference is in the SATB buffer, right? > > It works a bit differently in every GC. But I think the common theme is > that after > you start concurrently marking at a snapshot in time, all new > allocations from that > point and onward, will not be considered for being GC:ed this cycle, and > hence won't > be visited. TLABs are retired, so that new TLABs are created in some new > space that is > not collected. If you manage to write a reference from the allocated > object to a an object > that is older than when concurrent GC started, then at the point you > performed a write > to this object, then either > 1) The reference you are writing is a root, and the collector guarantees > everything that > ?? ? becomes a root is marked as it becomes a root (ZGC, C4). > 2) Due to the reference being a root, it must have been reachable at the > snapshot at the > ?? ? beginning (SATB collectors - G1, Shenandoah with > ShenandoahGCMode="satb"), or > ???? been added to a SATB buffer when said link was broken. > 3) At the point of writing said reference, the object is marked, or > shaded "gray" in the > ??? dijkstra tri-colour scheme (incremental update - CMS, Shenandoah > with ShenandoahGCMode="iu") > >>> However, I'm not sure what happens if you share objects that have >>> not finished running their constructor to e.g. a static field, and >>> another Java thread racingly reads it and tries to make sense out of >>> it.? Feels like that might be a bit awkward... >> There's always a StoreStore barrier before any user code starts >> executing. > > Ah. That sounds promising. The VM must ensure that an unsafely published Java object can never be seen to have any invalid internal VM state - headers etc. David ----- > Thanks, > /Erik > From david.holmes at oracle.com Mon Aug 31 04:18:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Aug 2020 14:18:18 +1000 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument In-Reply-To: <848EB368-B244-4376-91D0-770FF0141477@oracle.com> References: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> <848EB368-B244-4376-91D0-770FF0141477@oracle.com> Message-ID: Hi Igor, Update looks good. Thanks, David On 29/08/2020 4:18 am, Igor Ignatyev wrote: > Hi David, > > good point, parseArguments (or rather checkOption) does indeed validate that passed option is valid and has a valid value, yet for many options all values are treated as valid, so ill-formed command lines like `-debugee.vmkeys="${test.vm.opts} ${test.java.opts} -transport.address=dynamic` won't be spotted by ArgumentParser and its sub-classes, and I'm afraid in some cases might change tests' behavior unnoticeably. thus I've decided to add the check that we always have even number of double quotes: > >> diff -r 83f273f313aa test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java >> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Thu Aug 27 19:37:51 2020 -0700 >> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Fri Aug 28 11:16:24 2020 -0700 >> @@ -156,6 +156,10 @@ >> arg.append(" ").append(args[++i]); >> doubleQuotes += numberOfDoubleQuotes(args[i]); >> } >> + if (doubleQuotes % 2 != 0) { >> + throw new TestBug("command-line has odd number of double quotes:" + String.join(" ", args)); >> + } >> + >> list.add(arg.toString()); >> } >> setRawArguments(list.toArray(String[]::new)); > > > Thanks, > -- Igor > > >> On Aug 27, 2020, at 9:09 PM, David Holmes wrote: >> >> Hi Igor, >> >> In case there may be a parsing error and the command-line is ill-formed, should you abort if you reach the end of the arg list without finding an even number of double-quotes? Or will parseArguments already handle that? >> >> Otherwise the changes seem good. >> >> Thanks, >> David >> ----- >> >> On 28/08/2020 12:39 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>>> 99 lines changed: 19 ins; 20 del; 60 mod; >>> Hi all, >>> could you please review the patch which unblocks the rest of 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? >>> background from JBS: >>>> jtreg splits command line by space to get the list of arguments and there is no way to prevent that (nor thru escaping, nor by adding quotes). currently, PropertyResolvingWrapper handles that and joins multiple arguments within double quotes into one argument before passing it to the actual test class. the only place where it's needed is in the tests which use nsk/share/ArgumentParser (or more precisely nsk.share.jpda.DebugeeArgumentHandler and nsk/share/jdb/JdbArgumentHandler). >>>> >>>> in preparation for PropertyResolvingWrapper removal, ArgumentParser should be updated to handle the "split" argument on its own. >>> I've also taken the liberty to slightly clean up ArgumentParser. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>> testing: all the tests which use ArgumentParser (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 >>> Thanks, >>> -- Igor > From david.holmes at oracle.com Mon Aug 31 04:24:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Aug 2020 14:24:24 +1000 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> References: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> Message-ID: <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> Hi Igor, On 29/08/2020 5:32 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >> 118 lines changed: 32 ins; 36 del; 50 mod; > > Hi all, > > could you please review this small patch which updates StressOptions to adjust allocated time according to TIMEOUT_FACTOR? > > from JBS: >> nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress time for testing in slow/stress configurations, e.g. Xcomp. > > the patch also includes small clean up and refactoring, such as removal of unused c-tor and using switch instead if-elif. webrev w/o these changes -- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ Both webrevs seem to be the same. But the changes seem fine. Thanks, David > webrev: http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8252522 > testing: vmTestbase tests (in progress) > > Thanks, > -- Igor > From david.holmes at oracle.com Mon Aug 31 04:53:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Aug 2020 14:53:09 +1000 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") In-Reply-To: References: Message-ID: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> Hi Igor, On 29/08/2020 1:52 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >> 145 lines changed: 28 ins; 22 del; 95 mod; > > > Hi all, > > could you please review this trivial clean up which replaces System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where appropriate? > > while updating these files, I've also cleaned them up a bit, removed unneeded imports, added/removed spaces, etc > > testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on {linux,windows,macos}-x64 > JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 > webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 Generally seems fine (though the fact the patch file contained a series of changesets threw me initially!) test/hotspot/jtreg/runtime/signal/SigTestDriver.java // add test specific arguments w/o signame cmd.addAll(Arrays.asList(args) - .subList(1, args.length)); + .subList(1, args.length)); Your changed line doesn't have the right indent. Can this just be put on one line anyway: // add test specific arguments w/o signame cmd.addAll(Arrays.asList(args).subList(1, args.length)); that seems better to me as the fact there is only one argument seems clearer. Though for greater clarity perhaps: // add test specific arguments w/o signame var argList = Arrays.asList(args).subList(1, args.length); cmd.addAll(argList); -- + Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) + .filter(s -> !s.isEmpty()) + .filter(s -> s.startsWith("-X")) + .flatMap(arg -> Stream.of("-vmopt", arg)) + .collect(Collectors.toList()); The preferred/common style for chained stream operations is to align the dots: Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) .filter(s -> !s.isEmpty()) .filter(s -> s.startsWith("-X")) .flatMap(arg -> Stream.of("-vmopt", arg)) .collect(Collectors.toList()); --- test/lib/jdk/test/lib/process/ProcessTools.java - System.out.println("\t" + t + - " stack: (length = " + stack.length + ")"); + System.out.println("\t" + t + + " stack: (length = " + stack.length + ")"); The original code is more stylistically correct - when breaking arguments across lines the indent should align with the start of the arguments. Similarly here: + return String.format("--- ProcessLog ---%n" + + "cmd: %s%n" + + "exitvalue: %s%n" + + "stderr: %s%n" + + "stdout: %s%n", + getCommandLine(pb), exitValue, stderr, stdout); should be: + return String.format("--- ProcessLog ---%n" + + "cmd: %s%n" + + "exitvalue: %s%n" + + "stderr: %s%n" + + "stdout: %s%n", + getCommandLine(pb), exitValue, stderr, stdout); and here: + String executable = Paths.get(Utils.TEST_NATIVE_PATH, executableName) + .toAbsolutePath() + .toString(); indentation again. Thanks, David ----- > Thanks, > -- Igor > From erik.osterlund at oracle.com Mon Aug 31 08:42:46 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 31 Aug 2020 10:42:46 +0200 Subject: RFR: 8252368 : Undo JDK-8245002: Windows GDI functions don't support NUMA interleaving In-Reply-To: References: <7eccbe79-232b-a392-f89d-cdba9fb455a4@oracle.com> Message-ID: <31dffc00-de07-3ec9-d6be-d3009d35a1eb@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2020-08-26 13:57, Stefan Karlsson wrote: > This was intended to go to hotspot-dev. Please review on that list. > BCC:ing hotspot-gc-dev. > > On 2020-08-26 13:53, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to re-enable NUMA interleaving on Windows. >> >> https://cr.openjdk.java.net/~stefank/8252368/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8252368 >> >> In JDK 15 we put in code that turns off NUMA interleaving if it is >> detected that Windows GDI functions don't work with split memory >> reservations. Later in JDK 16, and JDK 15.0.1, the code that uses GDI >> was rewritten to have a fallback mechanism for these kinds of >> problems (JDK-8240654). Because of that we don't need the workaround >> to turn off NUMA interleaving anymore. >> >> We also pushed a similar workaround patch to turn off large pages >> (JDK-8245000). That is dealt with in a separate RFR (JDK-8252367). >> This patch builds upon the changes in JDK-8252367. >> >> I tested locally that the reproducer in JDK-8245000 doesn't reproduce >> with the proposed patch. I also tested that also reverting the patch >> in JDK-8240654 causes reproducer to reproduce again. >> >> Thanks, >> StefanK From kim.barrett at oracle.com Mon Aug 31 08:43:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 31 Aug 2020 04:43:03 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> Message-ID: > On Aug 28, 2020, at 3:46 PM, Kim Barrett wrote: > I think that macro is okay. I would be even happier with it if we had > variable templates for the type traits, a la C++17, so > > std::is_integral::value => std::is_integral_v > > We could add a suite of IsIntegralV &etc variable templates. Though I think I?d rather not provide them that way. > Alternatively, > I wonder how much trouble we might be taking on if we conditionally defined > them with something like > > #if __cplusplus == 201402L > namespace std { > template constexpr bool is_integral_v = std::is_integral::value; > ... > } > #endif // __cplusplus I think adding them this way is worth considering, though not part of *this* change. > (Note that we can't get *exactly* the behavior of C++17 for these, since > inline variables are a C++17 language feature. The difference is linkage, > but I don't expect anyone to care whether `&IsIntegralV` in different > translation units result in the same address.) From stefan.karlsson at oracle.com Mon Aug 31 08:54:27 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 31 Aug 2020 10:54:27 +0200 Subject: RFR: 8252368 : Undo JDK-8245002: Windows GDI functions don't support NUMA interleaving In-Reply-To: <31dffc00-de07-3ec9-d6be-d3009d35a1eb@oracle.com> References: <7eccbe79-232b-a392-f89d-cdba9fb455a4@oracle.com> <31dffc00-de07-3ec9-d6be-d3009d35a1eb@oracle.com> Message-ID: Thanks, Erik. StefanK On 2020-08-31 10:42, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. > > Thanks, > /Erik > > On 2020-08-26 13:57, Stefan Karlsson wrote: >> This was intended to go to hotspot-dev. Please review on that list. >> BCC:ing hotspot-gc-dev. >> >> On 2020-08-26 13:53, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to re-enable NUMA interleaving on Windows. >>> >>> https://cr.openjdk.java.net/~stefank/8252368/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8252368 >>> >>> In JDK 15 we put in code that turns off NUMA interleaving if it is >>> detected that Windows GDI functions don't work with split memory >>> reservations. Later in JDK 16, and JDK 15.0.1, the code that uses >>> GDI was rewritten to have a fallback mechanism for these kinds of >>> problems (JDK-8240654). Because of that we don't need the workaround >>> to turn off NUMA interleaving anymore. >>> >>> We also pushed a similar workaround patch to turn off large pages >>> (JDK-8245000). That is dealt with in a separate RFR (JDK-8252367). >>> This patch builds upon the changes in JDK-8252367. >>> >>> I tested locally that the reproducer in JDK-8245000 doesn't >>> reproduce with the proposed patch. I also tested that also reverting >>> the patch in JDK-8240654 causes reproducer to reproduce again. >>> >>> Thanks, >>> StefanK > From erik.osterlund at oracle.com Mon Aug 31 08:55:59 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 31 Aug 2020 10:55:59 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> Message-ID: <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> Hi Kim, On 2020-08-28 21:46, Kim Barrett wrote: >> On Aug 28, 2020, at 3:44 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> On 2020-08-27 22:47, Kim Barrett wrote: >>> That would work, as would a macro that takes a type. That is, both of >>> these work. >>> >>> #define ENABLE_IF_T(...) EnableIfT<__VA_ARGS__> = 0 >>> #define ENABLE_IF_X(...) EnableIfX<__VA_ARGS__> = 0 >>> >>> I didn't propose either of those because adding a macro just to eliminate >>> the trailing " = 0" doesn't seem worthwhile. >> I see. Yeah I can see how that might not feel worthwhile. Although in a way, >> I guess the macro would hide the implementation details of the enable if mechanism, >> that otherwise leak out to the enable if user. >> >>> I proposed both EnableIfT and EnableIfX because I don't think either alone >>> is worthwhile, though for different reasons. (Assume that if we only had one >>> that the T/X suffix would eventually be eliminated.) Both of them are >>> basically about reducing syntactic noise. >>> >>> EnableIfT alone doesn't deal well with expressions, [?] >>> >>> EnableIfX alone doesn't, in my opinion, carry its weight; just use >>> std::enable_if_t directly. [?] >>> >>> I considered not proposing them at all. While I think together they provide >>> enough to be worth having, I also think that's not blatantly clear and >>> obvious. A single macro supporting both is much more compelling. If both >>> were removed, I'm not sure what to do with EnableIfAnd/Or; retain in the >>> proposal or retract the proposal entirely. >> I once again understand that having just an alias type for std::enable_if_t >> that takes an int might not feel worth while. >> >> I can't believe I'm about to say this though, but what if you combine the >> two not worthwhile things into that macro... it just might become worthwhile >> combined (yes I think I am in favour of the macro while you are not - I don't >> know what is going on either!). > What have you done with the real Erik? What do you mean? Oh and I've started using an IDE with a GUI as well. Pretty cool that you can click buttons with your mouse like that. ...joking of course! >> So if we don't do anything, the template parameter SFINAE syntax would seemingly be: >> >> template::value, int> = 0> >> void foo (T t) { ... } >> >> And if we have an ENABLE_IF macro that takes values only (keeping to the convention >> we have to work with values only as discussed previously), it would be: >> >> template::value)> >> void foo (T t) { ... } >> >> Here, I think I would actually prefer using the macro that hides the implementation >> details how it works from the user, and in the API just focuses on only passing in >> the right condition. Also, not importantly, the identifier ENABLE_IF is not taken >> (while EnableIf is). That macro can also have some comments describing the trick >> at one point, which I think is quite useful on its own. >> >> I guess the macro itself would look like this: >> #define ENABLE_IF(...) std::enable_if_t<__VA_ARGS__ , int> = 0 > The macro needs to be > > #define ENABLE_IF(...) std::enable_if_t<(__VA_ARGS__), int> = 0 > > Otherwise one gets a mess from `ENABLE_IF(sizeof(T) > 4)` for example; the > angle bracket closes the template parameter list instead of being a greater > than operator. Good point. >> So this value SFINAE only macro for doing SFINAE using a template parameter seems like >> something that we can actually do without relying on any compiler bugs being fixed or >> refactoring the world in HotSpot (yet). And I think it is more readable than the return >> type SFINAE we have today (that requires extra lines for the return type, and you have >> to scratch your head to figure out what the actual return type is). I would say that >> such a value SFINAE macro is worthwhile doing, IMO. > This is the main point of all this, of course. As you know, I really dislike > the C++98 function template SFINAE syntax. So much so that I'd rather > delegate to class templates, as was done with the Atomic::*Impl classes. The > new style enabled by this C++11 feature changes everything. So I'm highly > motivated to reach some consensus on how we're going to use this new > feature. Agreed. > I think that macro is okay. I would be even happier with it if we had > variable templates for the type traits, a la C++17, so > > std::is_integral::value => std::is_integral_v > > We could add a suite of IsIntegralV &etc variable templates. Alternatively, > I wonder how much trouble we might be taking on if we conditionally defined > them with something like > > #if __cplusplus == 201402L > namespace std { > template constexpr bool is_integral_v = std::is_integral::value; > ... > } > #endif // __cplusplus > > (Note that we can't get *exactly* the behavior of C++17 for these, since > inline variables are a C++17 language feature. The difference is linkage, > but I don't expect anyone to care whether `&IsIntegralV` in different > translation units result in the same address.) That seems like a good idea. And yeah I really don't think that difference will matter at all. >> I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like >> having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa. >> >> What do you think? > I had code that used the combined type/value macro and was ready to move forward > with that until I tried testing with Visual Studio (sigh!). I?d prefer being able to use the > variable template forms of various traits, but could live without if need be. > > If we adopt this macro, I'm inclined to just drop the proposed > EnableIfAnd<...> and EnableIfOr. I?ve not encountered that many uses for the > Or case. The And case can be done with separate ENABLE_IF?s, and indeed there > is a little bit of benefit to doing so, as the compiler may give more helpful error messages > when trying to figure out why one of the cases failed. (Similar to why it?s better to split > conjunctive asserts.) That makes sense. Using the macro and dropping the EnableIf{And | Or} sounds good to me. Thanks, /Erik From erik.osterlund at oracle.com Mon Aug 31 09:05:47 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 31 Aug 2020 11:05:47 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> Message-ID: <16561110-7b03-3c2a-bbd4-bfea887c6beb@oracle.com> Hi Kim, On 2020-08-31 10:43, Kim Barrett wrote: >> On Aug 28, 2020, at 3:46 PM, Kim Barrett wrote: >> I think that macro is okay. I would be even happier with it if we had >> variable templates for the type traits, a la C++17, so >> >> std::is_integral::value => std::is_integral_v >> >> We could add a suite of IsIntegralV &etc variable templates. > Though I think I?d rather not provide them that way. > >> Alternatively, >> I wonder how much trouble we might be taking on if we conditionally defined >> them with something like >> >> #if __cplusplus == 201402L >> namespace std { >> template constexpr bool is_integral_v = std::is_integral::value; >> ... >> } >> #endif // __cplusplus > I think adding them this way is worth considering, though not part of *this* change. Agreed, we can open some other RFE for such things. Thanks, /Erik >> (Note that we can't get *exactly* the behavior of C++17 for these, since >> inline variables are a C++17 language feature. The difference is linkage, >> but I don't expect anyone to care whether `&IsIntegralV` in different >> translation units result in the same address.) From kim.barrett at oracle.com Mon Aug 31 09:18:45 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 31 Aug 2020 05:18:45 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> Message-ID: <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> > On Aug 31, 2020, at 4:55 AM, Erik ?sterlund wrote: > On 2020-08-28 21:46, Kim Barrett wrote: >>> So this value SFINAE only macro for doing SFINAE using a template parameter seems like >>> something that we can actually do without relying on any compiler bugs being fixed or >>> refactoring the world in HotSpot (yet). And I think it is more readable than the return >>> type SFINAE we have today (that requires extra lines for the return type, and you have >>> to scratch your head to figure out what the actual return type is). I would say that >>> such a value SFINAE macro is worthwhile doing, IMO. >> This is the main point of all this, of course. As you know, I really dislike >> the C++98 function template SFINAE syntax. So much so that I'd rather >> delegate to class templates, as was done with the Atomic::*Impl classes. The >> new style enabled by this C++11 feature changes everything. So I'm highly >> motivated to reach some consensus on how we're going to use this new >> feature. > > Agreed. > >> I think that macro is okay. I would be even happier with it if we had >> variable templates for the type traits, a la C++17, so >> >> std::is_integral::value => std::is_integral_v >> >> We could add a suite of IsIntegralV &etc variable templates. Alternatively, >> I wonder how much trouble we might be taking on if we conditionally defined >> them with something like >> >> #if __cplusplus == 201402L >> namespace std { >> template constexpr bool is_integral_v = std::is_integral::value; >> ... >> } >> #endif // __cplusplus >> >> [?] > > That seems like a good idea. And yeah I really don't think that difference will matter at all. > >>> I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like >>> having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa. >>> >>> What do you think? >> I had code that used the combined type/value macro and was ready to move forward >> with that until I tried testing with Visual Studio (sigh!). I?d prefer being able to use the >> variable template forms of various traits, but could live without if need be. >> >> If we adopt this macro, I'm inclined to just drop the proposed >> EnableIfAnd<...> and EnableIfOr. [?] > > That makes sense. Using the macro and dropping the EnableIf{And | Or} sounds good to me. OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the webrev because of the change then revert in the patch series.) Just a full, since there seems little point in an incremental. https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ From erik.osterlund at oracle.com Mon Aug 31 09:38:02 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 31 Aug 2020 11:38:02 +0200 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> Message-ID: <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> Hi Kim, Looks good. Thanks, /Erik On 2020-08-31 11:18, Kim Barrett wrote: >> On Aug 31, 2020, at 4:55 AM, Erik ?sterlund wrote: >> On 2020-08-28 21:46, Kim Barrett wrote: >>>> So this value SFINAE only macro for doing SFINAE using a template parameter seems like >>>> something that we can actually do without relying on any compiler bugs being fixed or >>>> refactoring the world in HotSpot (yet). And I think it is more readable than the return >>>> type SFINAE we have today (that requires extra lines for the return type, and you have >>>> to scratch your head to figure out what the actual return type is). I would say that >>>> such a value SFINAE macro is worthwhile doing, IMO. >>> This is the main point of all this, of course. As you know, I really dislike >>> the C++98 function template SFINAE syntax. So much so that I'd rather >>> delegate to class templates, as was done with the Atomic::*Impl classes. The >>> new style enabled by this C++11 feature changes everything. So I'm highly >>> motivated to reach some consensus on how we're going to use this new >>> feature. >> Agreed. >> >>> I think that macro is okay. I would be even happier with it if we had >>> variable templates for the type traits, a la C++17, so >>> >>> std::is_integral::value => std::is_integral_v >>> >>> We could add a suite of IsIntegralV &etc variable templates. Alternatively, >>> I wonder how much trouble we might be taking on if we conditionally defined >>> them with something like >>> >>> #if __cplusplus == 201402L >>> namespace std { >>> template constexpr bool is_integral_v = std::is_integral::value; >>> ... >>> } >>> #endif // __cplusplus >>> >>> [?] >> That seems like a good idea. And yeah I really don't think that difference will matter at all. >> >>>> I tried it in my usecase I mentioned, and I think it looks pretty good. Feels like >>>> having a nice comfortable sofa in the sewers. I think I want this nice comfortable sofa. >>>> >>>> What do you think? >>> I had code that used the combined type/value macro and was ready to move forward >>> with that until I tried testing with Visual Studio (sigh!). I?d prefer being able to use the >>> variable template forms of various traits, but could live without if need be. >>> >>> If we adopt this macro, I'm inclined to just drop the proposed >>> EnableIfAnd<...> and EnableIfOr. [?] >> That makes sense. Using the macro and dropping the EnableIf{And | Or} sounds good to me. > OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the > webrev because of the change then revert in the patch series.) Just a full, since there seems > little point in an incremental. > > https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ > > > From kim.barrett at oracle.com Mon Aug 31 13:43:40 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 31 Aug 2020 09:43:40 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> Message-ID: > On Aug 31, 2020, at 5:38 AM, Erik ?sterlund wrote: > > Hi Kim, > > Looks good. Thanks > > Thanks, > /Erik > > On 2020-08-31 11:18, Kim Barrett wrote: >> [?] OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the >> webrev because of the change then revert in the patch series.) Just a full, since there seems >> little point in an incremental. >> >> https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ From igor.ignatyev at oracle.com Mon Aug 31 19:03:25 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 31 Aug 2020 12:03:25 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java In-Reply-To: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> References: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> Message-ID: <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> ping? > On Aug 26, 2020, at 4:59 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 >> 287 lines changed: 60 ins; 200 del; 27 mod; > > Hi all, > > could you please review the patch which removes shell script from alloc001 test? > there are two small difference comparing to the original test: > - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) > - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' > > the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. > > webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) > JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 > testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 > > [1] https://bugs.openjdk.java.net/browse/JDK-8252401 > [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 > > Thanks, > -- Igor > From alexey.menkov at oracle.com Mon Aug 31 21:54:47 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 31 Aug 2020 14:54:47 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java In-Reply-To: <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> References: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> Message-ID: <146ac950-2b0b-b4ac-d957-9b6a9f01afcd@oracle.com> Hi Igor, Looks good in general. One question. As far as I see old test didn't run "sh ulimit" on Windows. So now the test requires cygwin to run? --alex On 08/31/2020 12:03, Igor Ignatyev wrote: > ping? > >> On Aug 26, 2020, at 4:59 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 >>> 287 lines changed: 60 ins; 200 del; 27 mod; >> >> Hi all, >> >> could you please review the patch which removes shell script from alloc001 test? >> there are two small difference comparing to the original test: >> - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) >> - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' >> >> the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 >> testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8252401 >> [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >> >> Thanks, >> -- Igor >> > From igor.ignatyev at oracle.com Mon Aug 31 22:03:26 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 31 Aug 2020 15:03:26 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java In-Reply-To: <146ac950-2b0b-b4ac-d957-9b6a9f01afcd@oracle.com> References: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> <146ac950-2b0b-b4ac-d957-9b6a9f01afcd@oracle.com> Message-ID: <9B0DB297-83B5-4098-BBD7-42370C8D3396@oracle.com> Hi Alex, AFAIK, cygwin always was and still is a requirement for both building and testing on windows, so it should not be a problem for anyone who is developing/testing OpenJDK on windows. Cheers, -- Igor > On Aug 31, 2020, at 2:54 PM, Alex Menkov wrote: > > Hi Igor, > > Looks good in general. > One question. > As far as I see old test didn't run "sh ulimit" on Windows. > So now the test requires cygwin to run? > > --alex > > On 08/31/2020 12:03, Igor Ignatyev wrote: >> ping? >>> On Aug 26, 2020, at 4:59 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 >>>> 287 lines changed: 60 ins; 200 del; 27 mod; >>> >>> Hi all, >>> >>> could you please review the patch which removes shell script from alloc001 test? >>> there are two small difference comparing to the original test: >>> - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) >>> - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' >>> >>> the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 >>> testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8252401 >>> [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >>> >>> Thanks, >>> -- Igor >>> From alexey.menkov at oracle.com Mon Aug 31 22:37:17 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 31 Aug 2020 15:37:17 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java In-Reply-To: <9B0DB297-83B5-4098-BBD7-42370C8D3396@oracle.com> References: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> <146ac950-2b0b-b4ac-d957-9b6a9f01afcd@oracle.com> <9B0DB297-83B5-4098-BBD7-42370C8D3396@oracle.com> Message-ID: <87aa2d79-d411-4787-45b8-9c1824834a10@oracle.com> I suppose with WSL cygwin is not required. But it should be OK as well. LGTM. --alex On 08/31/2020 15:03, Igor Ignatyev wrote: > Hi Alex, > > AFAIK, cygwin always was and still is a requirement for both building and testing on windows, so it should not be a problem for anyone who is developing/testing OpenJDK on windows. > > Cheers, > -- Igor > >> On Aug 31, 2020, at 2:54 PM, Alex Menkov wrote: >> >> Hi Igor, >> >> Looks good in general. >> One question. >> As far as I see old test didn't run "sh ulimit" on Windows. >> So now the test requires cygwin to run? >> >> --alex >> >> On 08/31/2020 12:03, Igor Ignatyev wrote: >>> ping? >>>> On Aug 26, 2020, at 4:59 PM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 >>>>> 287 lines changed: 60 ins; 200 del; 27 mod; >>>> >>>> Hi all, >>>> >>>> could you please review the patch which removes shell script from alloc001 test? >>>> there are two small difference comparing to the original test: >>>> - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) >>>> - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' >>>> >>>> the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 >>>> testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252401 >>>> [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >>>> >>>> Thanks, >>>> -- Igor >>>> >