In defense of the Windows x86-32 Port

[Ron Pressler]

Hi.
A couple of things.

1. All ports can support virtual threads — which are part of the Java SE specification — thanks to the “fallback” implementation that creates an OS thread for every virtual thread; it conforms to the spec, although doesn’t give you the scaling benefit that requires an implementation of continuations in the VM. I believe a similar fallback implementation is in the works for Panama’s foreign-function API, another feature that some ports have fallen behind on a “high quality” implementation.

2. The fact that a port, or any feature for that matter, has some good uses is not sufficient. The OpenJDK JDK is among the world’s most important software infrastructures, and has a high bar of quality as so much important software depends on it. For a port to continue being part of the OpenJDK JDK it needs people who *commit* to maintaining it at the requisite quality and pace, and sometimes the *level* of demand is insufficient to justify the investment required, especially if there is greater demand for other things that compete for that investment. You can try convincing the maintainers of the port that committing to it is worth their while, but ultimately it’s up to them. If no one is willing to commit to maintenance at the required level, the port can still continue being maintained at a lower commitment level (possibly by volunteer “hobbyists"), but outside the OpenJDK JDK project.

— Ron

On 26 Feb 2023, at 05:09, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:

I saw this JEP draft today: https://openjdk.org/jeps/8303167.  It suggests deprecating the 32-bit Windows port of OpenJDK.
And even though it’s “just a draft” it does mention Java 21 (which is pretty soon), so I thought I might as well put in my “two cents” now instead of waiting to see whether or not this ends up going anywhere.
The draft is written as though the (primary?) purpose of the port is to support running Java on 32-bit versions of Windows.
Those are indeed very rare, and getting even rarer.  But I appreciate the 32-bit builds even though I haven’t run a 32-bit version of Windows in ages.
Unlike MacOS, it is possible (and effortless) to run 32-bit executables on 64-bit Windows.  There are at least 2 reasons to do so:
The obvious reason is that maybe someone has some native code they’re calling via JNI, and they don’t have a 64-bit version handy.
The other reason is perhaps less obvious, and perhaps I’m the only person in the world who considers this a “reason” at all, but it motivated me to write this email so here it is:
The restriction to 32-bits is pretty effective as a poor man’s substitute for a proper sandbox.
For example, the draft JEP talks about Project loom, a topic near and dear to me.  When I first heard of Project loom, I wanted to run two silly experiments.
The first experiment was to launch as many “platform” threads as I could, and thus get a feel for how much they “cost”.  The second experiment was to do the same for “virtual” threads.
I actually carried out the first experiment, on a 32-bit JVM.  I did not dare to try the same experiment on a 64-bit JVM.
The reason is that I knew that with a 32-bit JVM, I would run out of address space before anything bad happened.
But if I tried the same thing with a 64-bit JVM, then for all I know I might bring my poor laptop to its knees and might even be forced to restart.
I’ve been eagerly awaiting Alexey Shipilev’s 32-bit port (is anyone else besides him working on this?) ever since then so I could try the “loom” part of the experiment.
I’ll be a bit disappointed if it never appears.

Anyway, that’s my two cents; thanks if you read this far.

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<http://publicresearch.barclays.com/>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html.
__________________________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230228/917c352c/attachment-0001.htm>