From tanksherman27 at gmail.com Tue May 6 01:00:15 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 6 May 2025 09:00:15 +0800 Subject: Windows/Zero In-Reply-To: References: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> Message-ID: Hi Andrew, This was more so to see whether anyone would find Windows/Zero helpful or whether anyone wanted it in all honesty (I now know there isn't really a demand for it anywhere :P). It was really just some work I did on the side and wondered if anyone would need it. > I find this curious as well. I expect some of it is related to > building on Windows with gcc, but I would certainly need a very strong > reason to change code we've been using for nearly two decades to > return null pointers. On the contrary this was actually to allow it to compile with VC, gcc is perfectly fine with zero size arrays. I am still confused how the existing code for Zero does operations on arrays with 0 size though (For instance, there is code that gets register names from an array of registers that is 0 sized on Zero since we have no registers there, which seems to be contradictory). I wonder if that is worth looking into. best regards, Julian On Tue, Apr 29, 2025 at 1:18?AM Andrew Hughes wrote: > > On 10:59 Thu 24 Apr , Kim Barrett wrote: > > On 4/22/25 8:46 AM, Julian Waters wrote: > > > Hi all, > > > > > > Zero currently cannot compile on Windows, and to my knowledge, has > > > never been able to compile on Windows. [...] > > > > > I don't recall anyone showing interest in having it compile on Windows > in the best part of twenty years that Zero has existed. As Thomas & > Kim have said, it is primarily used for supporting new architectures > which don't yet have a JIT. The emphasis is on the architecture side > of the platform, not the operating system. > > The only architectures Windows currently supports are x86 and aarch64. > x86 has had a JIT since OpenJDK's inception and the aarch64 port was > developed for Linux first, from which point it made more sense to add > Windows support to the existing JIT than for Zero. > > I have seen Zero used to build on plenty of architectures (ppc, s390, > mips, alpha) on the Linux side. But, performance wise, it really only > makes sense to do this when there is no other option and you need to > ship a build of some form. > > Zero was first developed at Red Hat because we had a problem to solve: > we needed to ship OpenJDK on all the architectures that used to ship > with gcj (x86, ppc, s390) but, at the time, OpenJDK only had x86 and > SPARC ports. Zero was a way to provide an OpenJDK build on PPC & s390 > in RHEL, even if most end users eventually went for another third > party JDK that did have a JIT. > > OpenJDK has since gained PPC and s390 JITs and this is why Zero does > not get as much testing as it once did. It's still useful to maintain > it for bootstrapping new ports, but the only place we regularly ship > builds using Zero is to support s390 on OpenJDK 8, where it doesn't > have a JIT. It looks like Debian builds on mips [0], so they may have > more experience with Zero on the newer JDKs. > > It's not clear to me what your aim is here. If you want a way to keep > OpenJDK working on Windows x86-32, then I would suggest it makes more > sense to revert the JIT removal than try to make Zero work. It's > likely to be a battle either way, given 32-bit support is being > removed across the board, but maintaining a JIT would be a more > satisfying end result. Unless performance has improved dramatically > since I last tried, I can't see anyone wanting to use Zero day to day > to run Java programs. > > If you're interested in Zero on Windows from an academic perspective, > then it might make more sense to target the update releases where > 32-bit support is still maintained (and especially 8u where Zero > is also being regularly built by us). > > I had a look over your patch and it seems to be trying to solve three > problems at once: building Zero on Windows, building on x86-32 and > building on Windows with gcc. Building an update release with the > supported Visual Studio compiler may well remove some of the issues > that are not down to Zero at all. I find it especially worrying to see > huge chunks of Zero code outside the Windows area deleted and some > return values replaced with null pointers. > > > > I started work again recently to get Zero working with VC. [...] > > > > > > I'd like to float the idea of supporting Windows/Zero properly. > > > [...] > > > > > > > > > Thoughts? > > > > Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit x86 Port": > > > > "Windows 10, the last Windows operating system to support 32-bit operation, > > will reach End of Life in October 2025." > > > > That suggests the community of 32-bit Windows users is very small, and will > > only get smaller. The delivery of that JEP and the fact that zero has never > > worked on Windows at all suggests the community of 32-bit Windows users with > > new development needs is essentially nonexistent. > > > > Yes. I'd add to this that anyone who wants to still run the JDK on > x86-32 Windows is unlikely to be satisfied with Zero as a replacement > for a JIT build. > > It also implies a further niche of those who really want 24 and later, > because 8, 11, 17 & 21 are still being actively maintained and support > Windows on x86-32. My first question would be why vendors don't seem > to even be offering x86-32 Windows builds of 21 [1] if there is a > demand for a JDK there. > > > So providing a way to run new versions of Java on 32-bit Windows doesn't seem > > to me to be at all motivating. > > > > A port needs an active community to be considered alive and supported. I > > don't see that here. All I see is potential costs, with no demonstrated gain. > > > > I agree. We've had our fair share of ports over the years that have > been supported at one time and then become broken. Shark springs to > mind [1]. Keeping a port working is a full time job. > > > I don't think "Ideally, Zero should run on any platform, so it not running on > > Windows would be surprising" is a good reason. I think the purpose of zero is > > to provide a stepping stone toward support for a new platform where none > > currently exists. That's not what we have here. > > Yes, 'platform' here should really be 'architecture'. The primary OS > for Zero was always Linux, and if it has worked on other POSIX > systems, that's been more a side effect of their similarity leading to > a lot of shared code. > > The only practical case I see for Zero on Windows is if it is > someone's chosen platform to develop a port to a new architecture, as > Thomas mentioned. Given the need for Windows to also support said > architecture, I would only expect such an effort to come from > Microsoft. > > > > > The addition of zero-specific conditionalization in shared code in this work > > seems quite suspicious, given that zero currently works for non-Windows. > > > > I find this curious as well. I expect some of it is related to > building on Windows with gcc, but I would certainly need a very strong > reason to change code we've been using for nearly two decades to > return null pointers. > > > Sorry to be raining on your parade, but this doesn't seem useful to me. > > > > Likewise. We might be able to be more positive if we knew what your > end goal was :) > > [0] https://packages.debian.org/search?keywords=openjdk-21&searchon=names&suite=testing§ion=all > [1] https://adoptium.net/en-GB/marketplace/?os=windows&arch=x86&version=21 > [2] https://bugs.openjdk.org/browse/JDK-8171853 > > Thanks, > -- > Andrew :) > Pronouns: he / him or they / them > Principal Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > Please contact via e-mail, not proprietary chat networks From thomas.stuefe at gmail.com Tue May 6 07:36:06 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 May 2025 09:36:06 +0200 Subject: Windows/Zero In-Reply-To: References: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> Message-ID: On Tue, May 6, 2025 at 3:03?AM Julian Waters wrote: > Hi Andrew, > > This was more so to see whether anyone would find Windows/Zero helpful > or whether anyone wanted it in all honesty (I now know there isn't > really a demand for it anywhere :P). It was really just some work I > did on the side and wondered if anyone would need it. > > > I find this curious as well. I expect some of it is related to > > building on Windows with gcc, but I would certainly need a very strong > > reason to change code we've been using for nearly two decades to > > return null pointers. > > On the contrary this was actually to allow it to compile with VC, gcc > is perfectly fine with zero size arrays. I am still confused how the > existing code for Zero does operations on arrays with 0 size though > (For instance, there is code that gets register names from an array of > registers that is 0 sized on Zero since we have no registers there, > which seems to be contradictory). I wonder if that is worth looking > into. > Typically, these arrays are not really 0-sized, but variable-sized. That is a typical old-style way of allocating dynamic arrays: define a structure that is a header to a table, with the zero-sized array as the last struct member. Over-allocate the structure. Now you have a table with a header, the table elements are automatically correctly aligned and accessible via the element member with array operator []. Among other things, this keeps spatial locality between table header and table elements, and reduces the number of fine-grained mallocs. Not all compilers allow zero-sized arrays, so you often find 1-sized-arrays instead. Cheers, Thomas > > best regards, > Julian > > On Tue, Apr 29, 2025 at 1:18?AM Andrew Hughes > wrote: > > > > On 10:59 Thu 24 Apr , Kim Barrett wrote: > > > On 4/22/25 8:46 AM, Julian Waters wrote: > > > > Hi all, > > > > > > > > Zero currently cannot compile on Windows, and to my knowledge, has > > > > never been able to compile on Windows. [...] > > > > > > > > I don't recall anyone showing interest in having it compile on Windows > > in the best part of twenty years that Zero has existed. As Thomas & > > Kim have said, it is primarily used for supporting new architectures > > which don't yet have a JIT. The emphasis is on the architecture side > > of the platform, not the operating system. > > > > The only architectures Windows currently supports are x86 and aarch64. > > x86 has had a JIT since OpenJDK's inception and the aarch64 port was > > developed for Linux first, from which point it made more sense to add > > Windows support to the existing JIT than for Zero. > > > > I have seen Zero used to build on plenty of architectures (ppc, s390, > > mips, alpha) on the Linux side. But, performance wise, it really only > > makes sense to do this when there is no other option and you need to > > ship a build of some form. > > > > Zero was first developed at Red Hat because we had a problem to solve: > > we needed to ship OpenJDK on all the architectures that used to ship > > with gcj (x86, ppc, s390) but, at the time, OpenJDK only had x86 and > > SPARC ports. Zero was a way to provide an OpenJDK build on PPC & s390 > > in RHEL, even if most end users eventually went for another third > > party JDK that did have a JIT. > > > > OpenJDK has since gained PPC and s390 JITs and this is why Zero does > > not get as much testing as it once did. It's still useful to maintain > > it for bootstrapping new ports, but the only place we regularly ship > > builds using Zero is to support s390 on OpenJDK 8, where it doesn't > > have a JIT. It looks like Debian builds on mips [0], so they may have > > more experience with Zero on the newer JDKs. > > > > It's not clear to me what your aim is here. If you want a way to keep > > OpenJDK working on Windows x86-32, then I would suggest it makes more > > sense to revert the JIT removal than try to make Zero work. It's > > likely to be a battle either way, given 32-bit support is being > > removed across the board, but maintaining a JIT would be a more > > satisfying end result. Unless performance has improved dramatically > > since I last tried, I can't see anyone wanting to use Zero day to day > > to run Java programs. > > > > If you're interested in Zero on Windows from an academic perspective, > > then it might make more sense to target the update releases where > > 32-bit support is still maintained (and especially 8u where Zero > > is also being regularly built by us). > > > > I had a look over your patch and it seems to be trying to solve three > > problems at once: building Zero on Windows, building on x86-32 and > > building on Windows with gcc. Building an update release with the > > supported Visual Studio compiler may well remove some of the issues > > that are not down to Zero at all. I find it especially worrying to see > > huge chunks of Zero code outside the Windows area deleted and some > > return values replaced with null pointers. > > > > > > I started work again recently to get Zero working with VC. [...] > > > > > > > > I'd like to float the idea of supporting Windows/Zero properly. > > > > [...] > > > > > > > > > > > > Thoughts? > > > > > > Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit > x86 Port": > > > > > > "Windows 10, the last Windows operating system to support 32-bit > operation, > > > will reach End of Life in October 2025." > > > > > > That suggests the community of 32-bit Windows users is very small, and > will > > > only get smaller. The delivery of that JEP and the fact that zero has > never > > > worked on Windows at all suggests the community of 32-bit Windows > users with > > > new development needs is essentially nonexistent. > > > > > > > Yes. I'd add to this that anyone who wants to still run the JDK on > > x86-32 Windows is unlikely to be satisfied with Zero as a replacement > > for a JIT build. > > > > It also implies a further niche of those who really want 24 and later, > > because 8, 11, 17 & 21 are still being actively maintained and support > > Windows on x86-32. My first question would be why vendors don't seem > > to even be offering x86-32 Windows builds of 21 [1] if there is a > > demand for a JDK there. > > > > > So providing a way to run new versions of Java on 32-bit Windows > doesn't seem > > > to me to be at all motivating. > > > > > > A port needs an active community to be considered alive and > supported. I > > > don't see that here. All I see is potential costs, with no > demonstrated gain. > > > > > > > I agree. We've had our fair share of ports over the years that have > > been supported at one time and then become broken. Shark springs to > > mind [1]. Keeping a port working is a full time job. > > > > > I don't think "Ideally, Zero should run on any platform, so it not > running on > > > Windows would be surprising" is a good reason. I think the purpose of > zero is > > > to provide a stepping stone toward support for a new platform where > none > > > currently exists. That's not what we have here. > > > > Yes, 'platform' here should really be 'architecture'. The primary OS > > for Zero was always Linux, and if it has worked on other POSIX > > systems, that's been more a side effect of their similarity leading to > > a lot of shared code. > > > > The only practical case I see for Zero on Windows is if it is > > someone's chosen platform to develop a port to a new architecture, as > > Thomas mentioned. Given the need for Windows to also support said > > architecture, I would only expect such an effort to come from > > Microsoft. > > > > > > > > The addition of zero-specific conditionalization in shared code in > this work > > > seems quite suspicious, given that zero currently works for > non-Windows. > > > > > > > I find this curious as well. I expect some of it is related to > > building on Windows with gcc, but I would certainly need a very strong > > reason to change code we've been using for nearly two decades to > > return null pointers. > > > > > Sorry to be raining on your parade, but this doesn't seem useful to me. > > > > > > > Likewise. We might be able to be more positive if we knew what your > > end goal was :) > > > > [0] > https://packages.debian.org/search?keywords=openjdk-21&searchon=names&suite=testing§ion=all > > [1] > https://adoptium.net/en-GB/marketplace/?os=windows&arch=x86&version=21 > > [2] https://bugs.openjdk.org/browse/JDK-8171853 > > > > Thanks, > > -- > > Andrew :) > > Pronouns: he / him or they / them > > Principal Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > > Please contact via e-mail, not proprietary chat networks > -------------- next part -------------- An HTML attachment was scrubbed... URL: