Community
Participate
Working Groups
This a patch to remove the 32-bit dependency in SWT. It has been tested on AMD64. It is a patch against Eclipse 2.0.1, and only affects the GTK version. The basic idea of the patch is to replace every jint that is used to hold a native pointer with a jlong, copying and type converting where necessary. This has a small performance impact, but it should enable SWT to work on both 32- and 64-bit machines. This patch solves most of the portability problems in SWT, but it has some remaining defects that affect portability, in increasing order of severity: 1. It assumes that gint is the same type as jint. This is easily fixed, and I have added an assertion in every place that needs to be changed. 2. It assumes that a pointer will fit in a jlong. This is true for most machines. 3. The SWT callback mechanism is not cognizant of the types of arguments. All that it does is count the number of args, assuming that the types are all effectively the same. On AMD64 and x86 this generally works, because each callback argument occupies a single register or stack slot, but this really needs to be redesigned. The patch is at ftp://people.redhat.com/aph/eclipse-64-diffs
This is a duplicate of bug 27577. Other than that, great work coming up with a patch! Everybody else (me definitely included) are just whining.
SN and SSQ to evaluate the patch. Andrew, the patch cannot be applied using Eclipse. Is there something we are missing? How was the file created? It's possible that Eclipse has a bug ...
I don't know about eclipse but the problem may be the same as with patch(1): It gets confused because of the spaces in filenames ("Eclipse SWT..."). I've sent Andrew a few updates to his patch. With these updates I can run eclipse with our J2SE build for AMD64.
Thanks, Juergen. I'll put up a new patch as soon as I'm clear exactly what your changes are. If people really cannot applythe patch I'll put up a compressed archive of the whole tree.
*** Bug 27577 has been marked as a duplicate of this bug. ***
Any news on the new patch or compressed archive?
I have posted a rebuilt 2.0.1 tree and more patches, largely based on Mr. Haley's work: http://gelato.uiuc.edu/projects/eclipse/ If the Eclipse team is willing to make some changes to ensure that future releases are 64 bit clean, I can help.
I have created a patch for Eclipse 2.1.1, based on Mr. Haley's work. It can be found at: http://people.redhat.com/faltaous/eclipse/
Ok, here is the thinking so far: We are planning to generate the 64-bit versions of SWT from the 32-bit versions. There are two parts to SWT: 1) The Java Code: We plan to find every place where an integer should be a pointer and mark it (probably using something like "int /*PTR*/"). There will be places where we need to fix the sizes of things as well and other glitches in the code. Once this is done, we will be able to run a script over SWT that changes all the int's to long's, giving a 64-bit version of the Java Code: 2) The C Code: Most of the C code is auto-generated. The tool that does this is not open source but we will probably make it be as part of the work. Anyways, we will run the tool on the 64-bit version of the Java code, giving a 64-bit version of the C code. There is some C code that is not auto-generated that will be hacked by hand using #typedefs, #define's, whatever. Once we have the Java and C code, it's a matter of building the DLL's and the source zip file. The plan is that this whole process becomes an automated part of the SWT build script. Things to note: - there will not be a 64-bit version of SWT in CVS. - since there will be millions of changes, the plan is to lock down SWT, change everything and then put it back, avoiding the horrible merge that will result. SWT committers check changes when they update from CVS. - since there will be a million changes, patches are not a good solution. - the patches in this bug report "point the way" but are out of date for 3.0. We will need to duplicate this kind of work. - we will be starting with GTK first to debug and validate the process Some people have pointed out that the 64-bit Java source can probably be made to work on 32-bit platforms. The problem we have with this is that we are optimizing for 64-bit when most desktop machines are 32-bit. At any point in time, we could decide that this statement is false and cut over to the 64-bit version, running it everywhere. Probably none of this can happen before EclipseCon (Feb 6). We are trying to work out the scheduling.
This sounds like a good plan. I guess this means that there will be a single source code release for both 64- and 32-bit platforms, and the appropriate rewriting and regeneration will be done as the first part of the SWT build. One other possibility: maybe the unprocessed code should not be "int /*PTR*/" but just "/*PTR*/".
Chrix now owns this problem.
Possibly it's good to limit pointers to 32bit in C code. Did somebody try to make IA64 version using compiler options like milp32 in gcc?
What is milp32? It better not be a compiler option that does all the work for us!
Mikhail, can you first verify that it is possible to link binaries compiled with milp32 with ordinary 64 bit binaries? If not, it won't be possible to run Eclipse with any 64 bit JVMs, which kind of defeats the point...
Re using 32-bit binaries: This is certainly a possibility, and it is one we considered for running on AMD64. In http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00597.html, rth wrote > hpux supports bothLP64 and ILP32 modes, but no one else does. However, even on platforms where ILP32 is supported, it is far from ideal and requires a full set of 32-bit libraries to be installed on the system. While this is a way to get Eclipse running, it's nothing like a long-term solution.
Update on what's been happening in the last 10 days... First, special thanks to Andrew Haley from RedHat for contributing this patch and answering my questions. - The GTK SWT source code now contains tags used to generate a 64 bit version of the SWT jar and C code. - The fragment org.eclipse.swt.gtk64 and the project org.eclipse.swt.tools have been created in the dev.eclipse.org repository. The fragment org.eclipse.swt.gtk64 now contains SWT native libraries for the AMD64 platform. The project org.eclipse.swt.tools hosts the tool used to produce the SWT JNI C code from the SWT java classes. - the SWT FAQ has been updated and contains an entry on how to build the 64 bit version of SWT GTK. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/faq.html#gtk64 We are working with the Eclipse build team to have the SWT binaries and sources built and posted along with the other SWT ports on the Eclipse download page. This port is NOT completed, it has just started. We are able to run the SWT ControlExample. We are working on supporting the junit tests, implementing more of the API and refactoring parts of the C code. Chris
Starting with N20040228: The SWT binaries and sources for Linux (AMD 64/GTK 2) are now part of the automated build and posted on the Eclipse download page.
I've tried a few simple tests with N20040228 and our current J2SE 1.4.2&1.5.0 builds for AMD64: The tests crashed right at startup in about 50% of all tries. Ie. it looks like there are still some pointers stored in (or truncated to) 32-bit ints and SWT only works if the real pointer happens to point into the first 2G of mem. All crashes seem to happen in OS.g_signal_lookup() with broken pointers like 0xffffffffe28b9c70 (which should have been 0x2ae28b9c70), I'll take a closer look at it if I find some time.
I spent a little time last night digging into this and I have come up with a bunch of changes (I think a fix to g_signal_lookup is included in there). I will attach a diff against N20040228 later tonight if it can help anyone.
In response to comment 18: I have opened bug 53388 Please open separate PR's against Platform / SWT / Linux GTK if you want to report further crashs and post patches. As indicated in comment 16, the build is known not to run through the junit tests yet and I will post an update when it is reasonably stable. The current nightly builds allow us to verify that new code checked in in GTK compiles on both 32 and 64 bit. Question to Juergen: I assume you are running the Blackdown 1.4 VM. Could you tell us what this VM return on 64 bit platform on AMD64 and Intel Itanium when running the following code: System.out.println(System.getProperty("os.arch"));
And second question to Juergen: How do you set up your system to have pointers like 0x2ae28b9c70? Do you actually have more than 4Go of RAM? Set up a huge swap partition or use some special compiler flags to fake it somehow? The pointers on our box here fit on 32 bit and consequently we don't test much of the 64 bit part. Thanks for any info on this.
In response to comment 20: os.arch is "amd64" on AMD64. We've used "x86_64" originally but when our code was integrated into Sun's 1.5 codebase, Sun decided to to use "amd64". We then made this change for 1.4.2 too. Ie. all publicly available version use "amd64". Even with Intel's IA-32e announcement, os.arch most likely will stay at "amd64". (Blackdown doesn't provide a VM for IA64 currently.) As for comment 21: You don't need a special setup to get pointers to mem > 4G on AMD64. It's actually quite easy to get them, e.g from mmap. It may be that HotSpot triggers this more easily than gcj, I've had to make quite a few changes to Andrew Haley's original patch in order to get Eclipse 2.0.1 working with HotSpot. (I've tried N20040228 on a dual Opteron machine with 1G and a 2.6.1 NUMA kernel.)
I opened a new bug 53430 with my patches, but now I noticed that maybe I should have used the one Christophe created - sorry about that.
I am unable to run eclipse with the patches on amd64. Eclipse complains about the fact that it cannot find the native swt libaries.It is necessary that I recompile these libaries, too? When I tried this, I get following error message: ld: unrecognized option '-pthread' I am using gentoo linux with gtk, if this helps somone. I consider a backporting of the nightly amd64 port to 3M7. Is that possible. There coulod not be so much differences: version 3038 - version 3041.
Yes, you do have to recompile the native libraries, and you do have to make sure the path to -lpthread is correct. Your problem is almost certainly caused by the fact that the linker is looking in /lib rather than /lib64 for your libraries. have a look at the Makefile to find out.
Volkher: yes the native libraries are different - the SWT native libraries can be found under the org.eclipse.swt.gtk64/os/linux/amd64 folder in the Eclipse.org repository. The eclipse executable for AMD64 can be found under platform-launcher/bin/library/gtk64. We are working with the Eclipse build team to add the AMD64 Eclipse to the download page. It will be easier for you to try it then. I will provide an update when this experimental build becomes available. This platform is experimental, unstable and on progress at this stage. Please open separate PR's (SWT/Linux GTK) to report issues.
Update: the AMD64 GTK2 eclipse build is available on the download page (see the I20040310 integration build in particular). It is under development and we encourage you to open separate PR's to track missing features/fix crashes etc. AMD64 users: which 1.4 VM are you using? There appears to be a blackdown 1.4 VM at: ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/JDK- 1.4.2/amd64/rc1/ , from the blackdown website: http://www.blackdown.org/java- linux/mirrors.html
Yes, that is the one I am using - I am hoping to see the real release soon which has been rumoured for a while...any comments, Juergen? ;o) There is the Sun 1.5 Beta 1 as well, but I haven't come around to try that one yet, but maybe I will do that when testing the integration release. I have also been looking at what IBM has to offer in this area - you don't happen to have any insider information on whether there is something on the way?
I've downloaded the I20040322 AMD64 GTK2 build, and eclipse doesn't start up. I see that a bunch of patches were submitted in bug# 53430 that fixed the startup problems, and based on the comments, these changes have been incorporated. Does the latest build successfully startup eclipse? FYI: I've tried using both blackdown's 1.4.2 JVM as well as Sun's 1.5.0 beta for AMD64.
Peter: please open a separate PR and attach any log you may have. I20040322 comes up on our machine with the VMs you indicated. It sometimes crashes with the jit enabled (bug 55806). Thanks!
Andrew Haley, Christophe Cornu, can you close this bug as FIXED? Since 64 bit SWT builds for both IA64 and AMD64 can be downloaded from "http://download.eclipse.org/downloads/drops/R-3.0.1-200409161125/index.php#swt", this has obviously been fixed.
closing PR.
