From kim.barrett at oracle.com Sat May 2 09:59:32 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 2 May 2020 05:59:32 -0400 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> Message-ID: <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> > On Apr 30, 2020, at 6:24 AM, Thomas Schatzl wrote: > > Hi, > > On 29.04.20 14:28, Kim Barrett wrote: >> Please review this Windows-specific change to the initialization of >> UseNUMAInterleaving. >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8243961 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8243961/open.00/ >> Testing: >> mach5 tier1-3 >> mach5 testing on Windows with explict +UseG1GC +UseNUMA +ForceNUMA and >> each of +/-/(default)UseNUMAInterleaving. >> TestUseNUMAInterleaving fails for some of those test configurations on >> non-NUMA hardware, because the test expects UseNUMAInterleaving to be >> enabled if UseNUMA is enabled. As the test failure can only happen >> with +ForceNUMA, that configuration doesn't seem to otherwise lead to >> other problems, +ForceNUMA doesn't seem to be a tested configuration, >> and ForceNUMA is going away (JDK-8243628), we'll not worry about that >> failure. > > Change is okay, but what do you think about always disabling UseNUMA regardless of ForceNUMA on Windows instead? > > There does not seem to be a code path in the windows OS files that acts on UseNUMA. For NUMA related methods it returns default values, so any path in the GCs will just do nothing or act on useless default values from the os layer and do weird things. > > UseNUMAInterleaving is completely separate from UseNUMA functionality anyway (although "UseNUMA" is misleading at least to me, but that's another discussion). > > There is the problem then that probably many people enable UseNUMA to get UseNUMAInterleaving, but that could be handled in a windows specific way too. I.e. when -XX:+UseNUMA and -XX:+/-ForceNUMA is set, disable UseNUMA and enable UseNUMAInterleaving. > > That sounds much easier to understand to me than the current change. > > Some collectors (Z, Shenandoah) will set UseNUMA, but this evaluation is before os::init_2 so above idea would do the right thing as neither have any special UseNUMA path. I.e. both actually seem to want UseNUMAInterleaving. Shenandoah explicitly says so, so actually changing them to enable UseNUMAInterleaving instead of UseNUMA would be good too imo. > > On non-Windows there will be no difference to now. > > Thomas [Added ppc-aix-port-dev, as there is a small AIX change here.] I considered just unconditionally disabling UseNUMA on Windows. That would also be sufficient to fix the bug, since the later +UseNUMA => +UseNUMAInterleaving wouldn't happen. But I felt that was leaving a booby trap for whoever gets to deal with implementing UseNUMA on Windows. To avoid that, the later +UseNUMA => +UseNUMAInterleaving needs to be suppressed anyway. In which case there's no need (for this bug) to do anything about UseNUMA/ForceNUMA. Also, that would be a behavioral change if someone is actually using -XX:+ForceNUMA (and either -XX:+UseNUMA or using a collector that implicitly turns it on (ZGC and Shenandoah)) and expecting the current behavior that -XX:+UseNUMAInterleaving will also be implicitly enabled. Not that I think that's likely, but with ForceNUMA still being a product option... For other platforms I don't want to get into second guessing whether someone said +UseNUMA but really meant +UseNUMAInterleaving. I looked at moving the defaulting of +UseNUMAInterleaving when +UseNUMA earlier. It could be done in Arguments::apply_ergo. But then if UseNUMA ends up ultimately getting disabled we should undo that defaulting. Bleh! Digging further into this, I discovered that on Linux (at least) -XX:+UseNUMAInterleaving is effectively ignored if -UseNUMA, but not really in a good way. +UseNUMAInterleaving controls whether numa_make_global gets called in a couple of places. But that calls into stuff that is setup by libnuma_init, which is only called if +UseNUMA. numa_make_global copes with that lack of setup by checking for it and (not completely trivially) doing nothing if not set up. What I've ended up doing is moving the conditional enabling of UseNUMAInterleaving into the platform-specific code, where there's enough information to consistently get it right. I've also made all the os variants be explicit about UseNUMA and UseNUMAInterleaving; those that have no support for either now unconditionally set them false. (This happens to keep TestUseNUMAInterleaving working on those platforms.) New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ (No incremental; the code change to os_windows.cpp is the same, but the rationale and commentary are entirely different.) Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA added. TestUseNUMAInterleaving still fails on Windows with +UseNUMA +ForceNUMA on a single-node machine, because +UseNUMAInterleaving gets turned off, which is not what the test expects. Manually verified that on Linux -XX:+UseNUMAInterleaving alone gets overridden off when libnuma_init is patched to fail. From thomas.schatzl at oracle.com Mon May 4 09:43:59 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 4 May 2020 11:43:59 +0200 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> Message-ID: <419d123d-ee49-38cd-7ac2-b0b1039e0bfe@oracle.com> Hi, On 02.05.20 11:59, Kim Barrett wrote: >> On Apr 30, 2020, at 6:24 AM, Thomas Schatzl >> wrote: >> >> Hi, >> >> On 29.04.20 14:28, Kim Barrett wrote: >>> Please review this Windows-specific change to the initialization >>> of UseNUMAInterleaving. [?] CR: >>> https://bugs.openjdk.java.net/browse/JDK-8243961 Webrev: >>> https://cr.openjdk.java.net/~kbarrett/8243961/open.00/ Testing: >>> mach5 tier1-3 mach5 testing on Windows with explict +UseG1GC >>> +UseNUMA +ForceNUMA and each of >>> +/-/(default)UseNUMAInterleaving. TestUseNUMAInterleaving fails >>> for some of those test configurations on non-NUMA hardware, >>> because the test expects UseNUMAInterleaving to be enabled if >>> UseNUMA is enabled. As the test failure can only happen with >>> +ForceNUMA, that configuration doesn't seem to otherwise lead to >>> other problems, +ForceNUMA doesn't seem to be a tested >>> configuration, and ForceNUMA is going away (JDK-8243628), we'll >>> not worry about that failure. >> >> Change is okay, but what do you think about always disabling >> UseNUMA regardless of ForceNUMA on Windows instead? >> >> There does not seem to be a code path in the windows OS files that >> acts on UseNUMA. For NUMA related methods it returns default >> values, so any path in the GCs will just do nothing or act on >> useless default values from the os layer and do weird things. >> >> UseNUMAInterleaving is completely separate from UseNUMA >> functionality anyway (although "UseNUMA" is misleading at least to >> me, but that's another discussion). >> >> There is the problem then that probably many people enable UseNUMA >> to get UseNUMAInterleaving, but that could be handled in a windows >> specific way too. I.e. when -XX:+UseNUMA and -XX:+/-ForceNUMA is >> set, disable UseNUMA and enable UseNUMAInterleaving. >> >> That sounds much easier to understand to me than the current >> change. >> >> Some collectors (Z, Shenandoah) will set UseNUMA, but this >> evaluation is before os::init_2 so above idea would do the right >> thing as neither have any special UseNUMA path. I.e. both actually >> seem to want UseNUMAInterleaving. Shenandoah explicitly says so, so >> actually changing them to enable UseNUMAInterleaving instead of >> UseNUMA would be good too imo. >> >> On non-Windows there will be no difference to now. >> >> Thomas > > [Added ppc-aix-port-dev, as there is a small AIX change here.] > [...] > What I've ended up doing is moving the conditional enabling of > UseNUMAInterleaving into the platform-specific code, where there's > enough information to consistently get it right. I've also made all > the os variants be explicit about UseNUMA and UseNUMAInterleaving; > those that have no support for either now unconditionally set them > false. (This happens to keep TestUseNUMAInterleaving working on > those platforms.) > > New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ > > (No incremental; the code change to os_windows.cpp is the same, but > the rationale and commentary are entirely different.) os_linux.cpp: s/explicilty/explictly (pre-existing, may ignore) There is an inconsistency in the use of FLAG_SET_ERGO vs. directly setting flag values when the implementation does not support NUMA. E.g. on bsd FLAG_SET_ERGO is used to disable UseNUMA*, on Windows it is directly set to false when not setting ForceNUMA. Since ForceNUMA is "soon" going away it's not a big issue for me though. > > Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA > added. > > TestUseNUMAInterleaving still fails on Windows with +UseNUMA > +ForceNUMA on a single-node machine, because +UseNUMAInterleaving > gets turned off, which is not what the test expects. One option could be to add a @requires vm.opt.ForceNUMA != true to avoid unnecessary failures. > > Manually verified that on Linux -XX:+UseNUMAInterleaving alone gets > overridden off when libnuma_init is patched to fail. > > Thanks, Thomas From kim.barrett at oracle.com Tue May 5 06:24:47 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 May 2020 02:24:47 -0400 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <419d123d-ee49-38cd-7ac2-b0b1039e0bfe@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> <419d123d-ee49-38cd-7ac2-b0b1039e0bfe@oracle.com> Message-ID: <0F2351BC-600C-4C23-AADA-A44EBA15909D@oracle.com> > On May 4, 2020, at 5:43 AM, Thomas Schatzl wrote: > On 02.05.20 11:59, Kim Barrett wrote: >> [Added ppc-aix-port-dev, as there is a small AIX change here.] > [...] >> What I've ended up doing is moving the conditional enabling of UseNUMAInterleaving into the platform-specific code, where there's enough information to consistently get it right. I've also made all the os variants be explicit about UseNUMA and UseNUMAInterleaving; those that have no support for either now unconditionally set them false. (This happens to keep TestUseNUMAInterleaving working on >> those platforms.) >> New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ >> (No incremental; the code change to os_windows.cpp is the same, but the rationale and commentary are entirely different.) > > os_linux.cpp: s/explicilty/explictly (pre-existing, may ignore) > > There is an inconsistency in the use of FLAG_SET_ERGO vs. directly setting flag values when the implementation does not support NUMA. E.g. on bsd FLAG_SET_ERGO is used to disable UseNUMA*, on Windows it is directly set to false when not setting ForceNUMA. > > Since ForceNUMA is "soon" going away it's not a big issue for me though. I think the places that are setting UseNUMA based on ForceNUMA aren't "ergonimic"; they are doing exactly what the user directly requested. If ForceNUMA were removed I'd make those places use FLAG_SET_ERGO. >> Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA >> added. >> TestUseNUMAInterleaving still fails on Windows with +UseNUMA +ForceNUMA on a single-node machine, because +UseNUMAInterleaving >> gets turned off, which is not what the test expects. > > One option could be to add a @requires vm.opt.ForceNUMA != true to avoid unnecessary failures. I thought about that but prefer to leave the test alone, rather than (perhaps temporarily) conditionalize for an option that is being deprecated. From stefan.johansson at oracle.com Tue May 5 08:53:09 2020 From: stefan.johansson at oracle.com (stefan.johansson at oracle.com) Date: Tue, 5 May 2020 10:53:09 +0200 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> Message-ID: <966fa1ac-ee59-303d-3cc9-f4082ea791c4@oracle.com> On 2020-05-02 11:59, Kim Barrett wrote: > > New webrev: > https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ Looks good. Just one small thing and I know people have different opinions about this, so ignore this if you like. NUMA isn't supported on AIX, so I think it would make more sense to use FLAG_SET_DEFAULT there. No need for a re-review, Stefan > > (No incremental; the code change to os_windows.cpp is the same, but > the rationale and commentary are entirely different.) > > Testing: > mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA added. > > TestUseNUMAInterleaving still fails on Windows with +UseNUMA > +ForceNUMA on a single-node machine, because +UseNUMAInterleaving gets > turned off, which is not what the test expects. > > Manually verified that on Linux -XX:+UseNUMAInterleaving alone gets > overridden off when libnuma_init is patched to fail. > > From thomas.schatzl at oracle.com Tue May 5 08:55:24 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 5 May 2020 10:55:24 +0200 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <0F2351BC-600C-4C23-AADA-A44EBA15909D@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> <419d123d-ee49-38cd-7ac2-b0b1039e0bfe@oracle.com> <0F2351BC-600C-4C23-AADA-A44EBA15909D@oracle.com> Message-ID: <32ade27e-b8a8-1521-d2af-e500a9795326@oracle.com> Hi, On 05.05.20 08:24, Kim Barrett wrote: >> On May 4, 2020, at 5:43 AM, Thomas Schatzl wrote: >> On 02.05.20 11:59, Kim Barrett wrote: >>> [Added ppc-aix-port-dev, as there is a small AIX change here.] >> [...] >>> What I've ended up doing is moving the conditional enabling of UseNUMAInterleaving into the platform-specific code, where there's enough information to consistently get it right. I've also made all the os variants be explicit about UseNUMA and UseNUMAInterleaving; those that have no support for either now unconditionally set them false. (This happens to keep TestUseNUMAInterleaving working on >>> those platforms.) >>> New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ >>> (No incremental; the code change to os_windows.cpp is the same, but the rationale and commentary are entirely different.) >> >> os_linux.cpp: s/explicilty/explictly (pre-existing, may ignore) >> >> There is an inconsistency in the use of FLAG_SET_ERGO vs. directly setting flag values when the implementation does not support NUMA. E.g. on bsd FLAG_SET_ERGO is used to disable UseNUMA*, on Windows it is directly set to false when not setting ForceNUMA. >> >> Since ForceNUMA is "soon" going away it's not a big issue for me though. > > I think the places that are setting UseNUMA based on ForceNUMA aren't > "ergonimic"; they are doing exactly what the user directly requested. > If ForceNUMA were removed I'd make those places use FLAG_SET_ERGO. > >>> Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA >>> added. >>> TestUseNUMAInterleaving still fails on Windows with +UseNUMA +ForceNUMA on a single-node machine, because +UseNUMAInterleaving >>> gets turned off, which is not what the test expects. >> >> One option could be to add a @requires vm.opt.ForceNUMA != true to avoid unnecessary failures. > > I thought about that but prefer to leave the test alone, rather than > (perhaps temporarily) conditionalize for an option that is being > deprecated. > Okay, all good. Thomas From kim.barrett at oracle.com Tue May 5 09:20:00 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 May 2020 05:20:00 -0400 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <32ade27e-b8a8-1521-d2af-e500a9795326@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> <419d123d-ee49-38cd-7ac2-b0b1039e0bfe@oracle.com> <0F2351BC-600C-4C23-AADA-A44EBA15909D@oracle.com> <32ade27e-b8a8-1521-d2af-e500a9795326@oracle.com> Message-ID: <3AC294FB-20E8-43EA-9A39-D7A884BB368D@oracle.com> > On May 5, 2020, at 4:55 AM, Thomas Schatzl wrote: > > Hi, > > On 05.05.20 08:24, Kim Barrett wrote: >>> On May 4, 2020, at 5:43 AM, Thomas Schatzl wrote: >>> On 02.05.20 11:59, Kim Barrett wrote: >>>> [Added ppc-aix-port-dev, as there is a small AIX change here.] >>> [...] >>>> What I've ended up doing is moving the conditional enabling of UseNUMAInterleaving into the platform-specific code, where there's enough information to consistently get it right. I've also made all the os variants be explicit about UseNUMA and UseNUMAInterleaving; those that have no support for either now unconditionally set them false. (This happens to keep TestUseNUMAInterleaving working on >>>> those platforms.) >>>> New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ >>>> (No incremental; the code change to os_windows.cpp is the same, but the rationale and commentary are entirely different.) >>> >>> os_linux.cpp: s/explicilty/explictly (pre-existing, may ignore) >>> >>> There is an inconsistency in the use of FLAG_SET_ERGO vs. directly setting flag values when the implementation does not support NUMA. E.g. on bsd FLAG_SET_ERGO is used to disable UseNUMA*, on Windows it is directly set to false when not setting ForceNUMA. >>> >>> Since ForceNUMA is "soon" going away it's not a big issue for me though. >> I think the places that are setting UseNUMA based on ForceNUMA aren't >> "ergonimic"; they are doing exactly what the user directly requested. >> If ForceNUMA were removed I'd make those places use FLAG_SET_ERGO. >>>> Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA >>>> added. >>>> TestUseNUMAInterleaving still fails on Windows with +UseNUMA +ForceNUMA on a single-node machine, because +UseNUMAInterleaving >>>> gets turned off, which is not what the test expects. >>> >>> One option could be to add a @requires vm.opt.ForceNUMA != true to avoid unnecessary failures. >> I thought about that but prefer to leave the test alone, rather than >> (perhaps temporarily) conditionalize for an option that is being >> deprecated. > > Okay, all good. > > Thomas Thanks. From kim.barrett at oracle.com Tue May 5 09:30:24 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 May 2020 05:30:24 -0400 Subject: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows In-Reply-To: <966fa1ac-ee59-303d-3cc9-f4082ea791c4@oracle.com> References: <3DECFF77-4124-48C9-8E81-6B6DA3460528@oracle.com> <0C046210-C74F-4872-B2EB-F59A3688C083@oracle.com> <966fa1ac-ee59-303d-3cc9-f4082ea791c4@oracle.com> Message-ID: > On May 5, 2020, at 4:53 AM, stefan.johansson at oracle.com wrote: > > > > On 2020-05-02 11:59, Kim Barrett wrote: >> New webrev: >> https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ > Looks good. Just one small thing and I know people have different opinions about this, so ignore this if you like. NUMA isn't supported on AIX, so I think it would make more sense to use FLAG_SET_DEFAULT there. I think a "default" should not override an explicit command line option. I think it would be confusing to have the output from -XX:+PrintFlagsFinal with an explicit -XX:+UseNUMA indicate in the output that the default value was used. By using FLAG_SET_ERGO the output will have "command line, ergonomic". From mikael.vidstedt at oracle.com Fri May 22 03:36:51 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 May 2020 20:36:51 -0700 Subject: RFR(XS): 8245521: Remove STACK_BIAS Message-ID: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> Please review this small change which removes the STACK_BIAS constant and its uses: JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ Background (from JBS): With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now always 0 and can be removed. Testing: Tier1 Cheers, Mikael From david.holmes at oracle.com Fri May 22 04:11:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 May 2020 14:11:09 +1000 Subject: RFR(XS): 8245521: Remove STACK_BIAS In-Reply-To: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> References: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> Message-ID: Hi Mikael, Looks good. I assume the change to GraalHotSpotVMConfig.java is to allow it to work with older VMs? Thanks, David On 22/05/2020 1:36 pm, Mikael Vidstedt wrote: > > Please review this small change which removes the STACK_BIAS constant and its uses: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ > > Background (from JBS): > > With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now always 0 and can be removed. > > > Testing: > > Tier1 > > Cheers, > Mikael > From matthias.baesken at sap.com Fri May 22 06:38:17 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 22 May 2020 06:38:17 +0000 Subject: RFR(XS): 8245521: Remove STACK_BIAS In-Reply-To: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> References: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> Message-ID: Hi Mikael, looks good, thanks for the cleanup . Best regards, Matthias -----Original Message----- From: ppc-aix-port-dev On Behalf Of Mikael Vidstedt Sent: Freitag, 22. Mai 2020 05:37 To: hotspot compiler ; hotspot-runtime-dev at openjdk.java.net runtime ; serviceability-dev ; ppc-aix-port-dev at openjdk.java.net Subject: RFR(XS): 8245521: Remove STACK_BIAS Please review this small change which removes the STACK_BIAS constant and its uses: JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ Background (from JBS): With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now always 0 and can be removed. Testing: Tier1 Cheers, Mikael From vladimir.kozlov at oracle.com Tue May 26 19:01:05 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 May 2020 12:01:05 -0700 Subject: RFR(XS): 8245521: Remove STACK_BIAS In-Reply-To: References: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> Message-ID: On 5/21/20 9:11 PM, David Holmes wrote: > Hi Mikael, > > Looks good. +1 > > I assume the change to GraalHotSpotVMConfig.java is to allow it to work with older VMs? Yes. stackBias will be set to 0 if STACK_BIAS is not present. Otherwise it will be set to STACK_BIAS value. Thanks, Vladimir > > Thanks, > David > > On 22/05/2020 1:36 pm, Mikael Vidstedt wrote: >> >> Please review this small change which removes the STACK_BIAS constant and its uses: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ >> >> Background (from JBS): >> >> With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now >> always 0 and can be removed. >> >> >> Testing: >> >> Tier1 >> >> Cheers, >> Mikael >> From mikael.vidstedt at oracle.com Tue May 26 19:46:25 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 26 May 2020 12:46:25 -0700 Subject: RFR(XS): 8245521: Remove STACK_BIAS In-Reply-To: References: <114B5A9A-DEF8-43AA-814A-3D7E7BD2B001@oracle.com> Message-ID: David/Matthias/Vladimir, thanks for the reviews! Change pushed. Cheers, Mikael > On May 26, 2020, at 12:01 PM, Vladimir Kozlov wrote: > > On 5/21/20 9:11 PM, David Holmes wrote: >> Hi Mikael, >> Looks good. > > +1 > >> I assume the change to GraalHotSpotVMConfig.java is to allow it to work with older VMs? > > Yes. stackBias will be set to 0 if STACK_BIAS is not present. Otherwise it will be set to STACK_BIAS value. > > Thanks, > Vladimir > >> Thanks, >> David >> On 22/05/2020 1:36 pm, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the STACK_BIAS constant and its uses: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ >>> >>> Background (from JBS): >>> >>> With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now always 0 and can be removed. >>> >>> >>> Testing: >>> >>> Tier1 >>> >>> Cheers, >>> Mikael >>>