Windows/Zero

Tue May 6 07:36:06 UTC 2025

On Tue, May 6, 2025 at 3:03 AM Julian Waters <tanksherman27 at gmail.com>
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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zero-dev/attachments/20250506/6cf84482/attachment-0001.htm>