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