[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] SWT on 64-bit platforms
|
Pointer math also produces addresses that can't be collected.
Tom Tromey
<tromey@xxxxxxxxxx> To: platform-swt-dev@xxxxxxxxxxx
Sent by: cc:
platform-swt-dev-admin@ Subject: Re: [platform-swt-dev] SWT on 64-bit platforms
eclipse.org
09/11/02 06:37 PM
Please respond to
platform-swt-dev
>>>>> "Steve" == Steve Northover <Steve_Northover@xxxxxxx> writes:
Steve> Only SWT is sensitive to 64-bits.
Thanks!
Steve> I forgot about the mapping table option. We had already
Steve> thought of that but it seemed really hacky and there is no way
Steve> to garbage collect the table.
My thinking was that you wouldn't need to GC the table, since you
already have to explicitly delete any Gtk object for which you have a
handle.
My current understanding is that any `int' representing an underlying
C pointer is basically using the C allocation model of explicit
freeing by the programmer. However, I can't claim enough familiarity
with SWT to be certain. Are there cases where the `int' values can be
"GC'd" (forgotten, I suppose) without a resulting memory leak?
Anyway, the situation is more complex than I first had hoped. For
instance the `sizeof' fields in places like class GdkColor need to be
audited for 64-bit cleanliness (this particular one appears to be
fine, but I didn't check any others).
Steve> The error message was the very cryptic "LA Table overflow".
Clearly this must be preserved if this approach is implemented :-)
Today I did a few random greps and code readings to try to orient
myself a bit. I'll do more tomorrow.
Thanks again for your help and insight.
Tom
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
