[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] SWT on 64-bit platforms
|
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 instead of wasting more time
exploring all the bad possibilities ... it's just a mess.
Steve
Tom Tromey
<tromey@xxxxxxxxxx> To: "Steve Northover" <Steve_Northover@xxxxxxx>
Sent by: cc: platform-swt-dev@xxxxxxxxxxx
platform-swt-dev-admin@ Subject: Re: [platform-swt-dev] SWT on 64-bit platforms
eclipse.org
09/12/02 02:16 PM
Please respond to
platform-swt-dev
>>>>> "Steve" == Steve Northover <Steve_Northover@xxxxxxx> writes:
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.
Tom
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
