Native support for Eclipse SDKs on Windows Arm64 #577
Comments
|
Did you update the features to include the new fragments?
|
|
@merks thanks for the tip. Your picture is worth more than a thousand words to me. Now I can build the Eclipse SDKs for WoA and they work! Next is where/what is the repo to build the Eclipse IDE (which should include other tools like JGit/EGit, m2e, etc.) for WoA? |
|
The repository used to build the IDE are composed from many projects. There's information about that here: https://ci.eclipse.org/simrel/ This file has information about all the projects involved: https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/simrel.aggran Quite of a few of the project has Oomph setups that you can use to setup an an IDE; many of them you'd have to do manually. |
|
I don't think you'll need to change many other projects. The very vast majority of them wouldn't have Platform specific artifacts, and I don't have the impression fixing those is an immediate requirement for you. But this is a multi-step process. My advice would be that -if you're willing to make your work sustainable and to contribute it to Eclipse Project-, now that you have a build working, you find a way to get a win32/aarch64 machine contributed to the build farm and contribute your changes to the Eclipse Platform/SDK project to get this Platform supported. Going to "official" SDK and p2 repo will already be a major milestones and will make it easier to cascade later on to SimRel/EPP... |
|
As to the problem with JNA bundle in WoA:
I've raised an issue with the JNA project: java-native-access/jna#1465 |
|
@mickaelistria My Arm64 box is an entry-level, slow box, suitable for some light, manual testing only. I had started building this repo with this Arm64 box, and it was a big exercise in patience. I eventually gave it up and switched to building on a Linux (x64) box instead. It takes around 1 hour to build this repo on the Linux box without running the tests (i.e. with The good news is that you don't need an Arm64 box to build these SDKs for WoA. I can build and produce all SDKs for all os/arch (WoA included) with my Linux (x64) box, so your existing build farm can build the WoA distribution too, once my work on WoA are accepted in to the official repos. The recompiled binaries for Arm64 would be checked in to the repos like other existing binaries currently for other os/arch, so that the build wouldn't depend on any platform-specific tools to run. From the look of it, building the Eclipse IDE for WoA is more than I can chew at the moment, so for now I will concentrate on submitting PRs for this WoA work to various repos (9 total, including this repo), to get the official Platform/SDK build started for WoA! |
|
@chirontt OK, thanks for the details. So if you have things that you could already contribute, please do so and we'll see what we can merge easily. But at some point, to guarantee good enough quality, we'll need to have the SDK tests running automatically on a win32/aarch64 machine. Without it, then the project cannot prevent from potential regressions easily, and we basically cannot provide good enough support ot make it reliable; which IMO kind of question the value of hosting this specific code in the Eclipse project instead of eg in some fork of yours. |
|
Can this aggregator build be run for Windows on Arm64 only, i.e. for If so, I would try to build just for this WoA platform on my Arm64 box, including running the tests, to see how it would fare in producing the SDKs for WoA. I can't give any promise at the moment, though. BTW, I've started sending out the PRs for this WoA work. |
|
Some of the CI issues such as the ones about not found bundles in https://ci.eclipse.org/equinox/job/equinox/job/PR-121/1/console are caused by the missing win32/win32/aarch64 declaration in the parent pom: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse-platform-parent/pom.xml#L254 . Please try adding the environment there and if build is fine, submitting a PR for that. |
|
We can have the bundles but can't include them in features/products until we have the builder to ensure that they are rebuild on source changes. |
|
Sorry for the confusion in my partial submission of PRs. I ran out of time yesterday, and only managed to submit the PRs for Now I've done all other PRs for My guess is that all these PRs need to go in together for a successful build, as they are inter-related, but you may have better idea about them. |
|
I'll repeat it: |
|
@daliasheasha You was interested in Eclipse on Windows AArch64. Maybe you can help with some builder? |
|
@akurtakov I'll resubmit the PRs if you can show me what can be submitted now, and what should be submitted later when the build farm would have a builder available to (re)build Windows on Arm64 artifacts. This requires in-depth knowledge of the overall build requirements of all the repos, knowledge that I don't have. Although I've withdrawn all the PRs, for the records, here was the list of them again that contains all of the WoA work in my forks: eclipse-equinox/equinox#121 The branches in my forks for them are still available, to be resubmitted to mainline if needed. From my point of view, submitting them all together would lessen the chance of build breakage, but you may have better idea. I know that all changes in those PRs would produce a successful Eclipse SDK for Windows on Arm64 platform, but separating them to do partial submits to mainline is a tough job for me, not to mention (God forbid!) build breakage. I'm willing to create new branches in my forks to submit the PRs again, if you can give me a precise list of what can be accepted, or wouldn't be needed (natives?), out of the above (withdrawn) PRs. |
|
FYI, my fork of this umbrella repo, for Windows-on-Arm64 support, is now available: https://github.com/chirontt/eclipse.platform.releng.aggregator The fork includes links to other forked submodules, to make up my whole Windows-on-Arm64 work. To build it is like normal (it can be built on any OS, be it Linux, Windows, or MacOS (haven't actually tried this myself)): The eventual build artifacts for all Eclipse SDKs of all os/arch will be produced in the And the specific artifact of my interest would be I will try to keep this fork tracking the upstream repo closely, to keep it from becoming outdated, perhaps by merging it with upstream repos every weekend. |
|
I did one of them in eclipse-platform/eclipse.platform.ui#365 (review) |
|
@waynebeaton Maybe you can try foundation MS connections for having win/aarch64 machine on the build farm? |
|
There's no need to have win/aarch64 machine to build bundles, see eclipse-platform/eclipse.platform.swt#413 (comment) Without such machine, we won't be able to run tests against built binaries, but this is only a minor issue: it's unlikely to have any new bugs compared to x64 bundle. |
|
I expect we'll want to be able to test that this stuff actually works. Also, if we want SimRel/EPP to deliver these things, will need a JustJ JRE for which we need to run jlink natively. If no one is willing to commit to providing hardware, what does that say about depth of the commitment? |
|
I said it already - it's fine to have sources for anyone willing to work on it. But it's not fine to ship any user binaries without being able to at least smoketest it. |
|
Hi folks - Martijn from Microsoft (and Eclipse Adoptium) here. I'm wondering if some of the Windows on ARM hosts we have at Eclipse Adoptium could be utilized for this project? I'll check with George Adams when he's back from leave and see what we can do. |
|
@karianna so is there progress on your arm hosts being available for releng jipp? |
|
An option is Project Volterra - https://blogs.windows.com/windowsdeveloper/2022/10/24/available-today-windows-dev-kit-2023-aka-project-volterra/ Not sure if we can do the Adoptium loan - CC @gdams |
|
I'm closing this one as there is clearly no interest from anyone to step up and do some work. If/when one does please reopen or create new issue. |
|
FYI: In the meantime, I'm putting out unofficial Eclipse SDK builds for Windows on Arm64 in my fork. I guess my fork will exist until Eclipse starts officially supporting Windows on Arm64 in its IDE releases. |
Thanks a lot, @chirontt ! That's the way forward as long as no one with resources cares enough to provide a single Windows Arm64 builder to the project to use. |
|
I've downloaded the Eclipse SDK for WoA from the latest I-build and ran it on my WoA box; seems to work fine, but here's its screenshot in dark mode:
Note the lighted scrollbars, they require the fix in eclipse-platform/eclipse.platform.swt#1172 to be dark again. Seems both the How do I check the auto-refresh feature? like, checking the auto-sync of the IDE with changes in the file system?
How should I benchmark this filesystem feature? Import a sizable project into the IDE and time it? (I have a sizable RCP project here to test it if needed.) Also, I have a slow box, so it may clearly show the difference as compared to a faster box. But I agree that we should remove these dependencies in native code as much as possible, given reasonably fast hardware available nowadays. |
Go to Preferences > Workspace > Refresh Using native Hooks or polling What will happen is that you open expand a project folder, then you go to the Windows Explorer and create a new file there. If Refresh/Polling is activated the file will be shown in Eclipse after some (hopefully short) time, otherwhise you need to press F5 on the folder. I think that's a part worth porting to You can find some discussions here:
There was recently a benchmark and the NIO is slightly You can find some discussions here including the benchmarks: I think its up to you if you think its worth to migrate this for |
Thank you Ed for checking.
That's great news. The SWT issue will hopefully be resolved soon.
Yes that would one option. You could for example compare the runtime of an explicit refreseh of all projects in the workspace or of a full clean+rebuild both should include a lot of IO (altough I have to admit I have not yet checked for which operations exactly the native file-system handler is used). And yes using a slow computer will probably show any difference better. I think all other questions have been answered by Christoph already. With that I think support for WoA is ready to be announced on the cross-project mailing list so that more people can try it out and give feedback. |
Per occasion, we re-run "our" real life application benchmark on Eclipse 4.30 platform and we still see native Eclipse code performing faster as Java 21 NIO on xfs.
Correct. |
|
Just created a New&Noteworthy entry for this: and an issue in EPP to track the delivery of all prepacked Eclipse packages for WoA: |
This avoids the native code necessary for JNI, while being only slightly slower. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower without noticable impact. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI, while being only slightly slower without noticable impact. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures on Windows. Also part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI and consequently the separate o.e.core.resources.win32.x86_64 fragment, while being only slightly slower without noticeable impact on the overall performance. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures supported on Windows out of the box. Also part of eclipse-platform/eclipse.platform.releng.aggregator#577
This avoids the native code necessary for JNI and consequently the separate o.e.core.resources.win32.x86_64 fragment, while being only slightly slower without noticeable impact on the overall performance. At the same time it allows to use the 'Win32RefreshProvider' on all CPU architectures supported on Windows out of the box. Also part of eclipse-platform/eclipse.platform.releng.aggregator#577
|
With eclipse-platform/eclipse.platform#1422 being submitted I think everything functional is done to support Windows on ARM. |
Update: now that adding support for Windows on Arm64 is under way for various Eclipse repositories, here's the central TODO list to keep track of various tasks done and/or under way:
eclipse.platform.swtsubmoduleequinoxsubmodulert.equinox.p2submoduleeclipse.platformsubmoduleeclipse.platform.uisubmoduleeclipse.platform.releng.aggregatorI'm trying to build the Eclipse SDKs for Windows 11 on Arm64 (WoA), using this repo. I hope this is the right repo to start with, which is the umbrella repo for all others.
The environment triplet I use for it is
win32/win32/aarch64, following the existingwin32/win32/x86_64triplet as a guide.After re-compiling many *.exe and *.dll native files for WoA in various repos (from existing C code mostly unchanged), and adding many new
win32.aarch64folders (most of them are duplicates of the existing win32.x86_64 ones), I've managed to build successfully this aggregator repo, and got the following new zip files ineclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/target/products(in addition to other supporting os/arch zip files there):After unzipping the
org.eclipse.sdk.ide-win32.win32.aarch64.zipfile, I discover that, in itseclipse/pluginsfolder, the following 6 bundles are missing:When compared to the
org.eclipse.sdk.ide-win32.win32.x86_64.zipdistribution, those bundles (of relevantx86_64arch) do exist there. So somehow they got missing from the final zip file foraarch64during the build.The missing bundles are crucial for the Eclipse SDK to properly start up, but I have no idea how they got missed out from the build artifacts. I think I must have skipped over some crucial file(s) somewhere which produced this missing result.
Is there a file somewhere in the repo to indicate which bundles to be included (in the
pluginsfolder of the zip file) for each SDK?PS. The missing bundles are actually produced in their own Maven modules during the build, in the
eclipse.platform&equinoxsubmodules. Once I manually add 4 of them (the other 2 are source bundles) to thepluginsfolder, and also add their missing entries to theconfiguration\org.eclipse.equinox.simpleconfigurator\bundles.infofile, starting it up witheclipse.exeworks nicely!PPS. Especially and crucially for WoA,
eclipse.execan only start up after I add the-Dorg.osgi.framework.os.name=win32,winentry to theeclipse.inifile, to help it resolve the criticalcom.sun.jnabundle at runtime.The text was updated successfully, but these errors were encountered: