Community
Participate
Working Groups
This PR is a placeholder for 64 bit platform support. The SWT implementation is currently targeted at 32 bit platforms. As such, many internal fields are taking advantage of this. The current ports are not 64 bit friendly. To support 64 bit architectures, a new port of SWT is required (or the current ones have to be reorganized in a different way if this can be done without sacrifying performance of the 32 bit ports).
*** Bug 27560 has been marked as a duplicate of this bug. ***
Pasting relevant discussions from the eclipse swt mailing list on this topic (thread from 9/12/2002). - Tom Tromey <tromey@redhat.com> said: I'd like to know if there is a plan to make SWT (in particular the Gtk port) work on 64-bit platforms. Right now the Gtk code uses `int' to represent handles, e.g.: [OS.java] public static final native int gtk_fixed_new(); and: [swt.c] return (jint)gtk_fixed_new(); These int values are 32-bits (per the Java spec), but are cast back and forth to pointers in the native code. That means the code isn't 64-bit clean. One fix would be to s/int/long/ in all places where the handle represents a pointer. Steve Northover said: Tom, there is no plan in place to port SWT to 64-bits. There are other places in the code where we are not 64-bit clean. We have thought about possible solutions: - 2 streams, one using "long" and one using "int" - abandon "int" and use an object that contains either an "int" or "long" (like TCHAR on Windows that hides UNICODE vs. DBCS) - use "SWT_int" (bad name) and run a preprocessor that produces either "int" or "long" - use "long" everywhere and be careful to do the correct casting/pointer math on 32-bit systems At the very least, we plan to begin marking places in the code where we have made this assumption. - Tom Tromey said: Steve> Tom, there is no plan in place to port SWT to 64-bits. There Steve> are other places in the code where we are not 64-bit clean. Do you mean other places in SWT, or other places in Eclipse in general? If you mean just SWT, that's ok; any 64-bit audit will likely find them. I don't know when exactly we may need this (or whether we will -- it all seems a bit speculative). Right now I'm just trying to estimate the magnitude for our planning. If you mean code other than SWT, do you know if there is a list of problem areas? That might help. Steve> We have thought about possible solutions: Steve> - 2 streams, one using "long" and one using "int" Yikes. Steve> - abandon "int" and use an object that contains either an "int" or Steve> "long" (like TCHAR on Windows that hides UNICODE vs. DBCS) Another similar choice would be to have a hash table on the native side that does the int/pointer mapping. It could be conditional on a the platform having 64-bit pointers. This seems like it would have less overhead than wrapping every native pointer in a new Java object. On the other hand it would seem to violate the general SWT approach (or what I understand it to be anyway). Steve> - use "long" everywhere and be careful to do the correct Steve> casting/pointer math on 32-bit systems IMO this is probably the simplest to implement and understand. Most likely I'll base my estimate on this. If you know for certain that one approach is unacceptable, that would help me. - Steve Northover said: Only SWT is sensitive to 64-bits. I forgot about the mapping table option. We had already thought of that but it seemed really hacky and there is no way to garbage collect the table. Microsoft Win32s used to use this strategy way back on Windows 3.11 to map between 32 and 16 bit pointers and they kept running out of space in their table. The error message was the very cryptic "LA Table overflow". One is reminded of the Doors song ... - Tom Tromey said: Steve> Pointer math also produces addresses that can't be collected. I still don't understand. I don't see when such memory can ever be collected in the java sense. It seems to me that it must always be explicitly freed according to the usual C rules. So if one of these `int' handles represents C-style memory, then you have to pass in the original value in order to free the memory. Mapping int->pointer is a problem in the presence of pointer arithmetic. But this could be addressed by putting object size information into the lookaside table. - Steve Northover said: There are just too many places to go wrong with a strategy like this. On Windows, you get called back with 64-bit WM_ parameters that need to be mapped to 32-bits before calling into Java. It means you need C code that knows about every WM_ so it knows which ones to map (some WM_'s pass addresses, some don't). Allocation has to stack. You can get called back from inside a callback and the same address gets passed so that only the last callback could free the 32-bit address from the table. If you want to interface with any 3rd party code, they will be using 64-bit pointers, we will be mapping pointers to the mapping table will have to be API. I think we can safely throw away this idea.
A patch exists and is being discussed in bug 37775 (which is also a duplicate of this).
*** This bug has been marked as a duplicate of 37775 ***
