Windows/Zero

Tue May 6 01:00:15 UTC 2025

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 <gnu.andrew at redhat.com> 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&section=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