Re: [platform-swt-dev] GTK in CVS

["Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx>]

Using 'long' everywhere will hurt performance, though perhaps
not noticeably.  Simply put, the VM has to do more work in
reading/writing/manipulating these values.  In particular, since the
architechture cannot easily manipulate 64bit values, the JIT will
be required to perform such things in two strokes.  Thankfully
the most SWT does with pointer/handle values is copying them
around (ie. no arithmetic), so this might not be all that bad.
Should try this out just to see...  Too bad Java doesn't have
typedefs...

We could write a tool to replace 'int' with 'long' and vice-
versa as part of a preprocessing stage for compilation.  This
would entail marking the locations where such conversions
must take place.  However, this would run counter to the
Java philosophy.  I don't like the idea but it would be better
than maintaining parallel code streams.

A third possibility:  I believe many commodity operating
systems on 64bit platforms offer the ability to execute
programs in a special 32bit memory model by using page
table tricks or platform facilities to make the upper 32bits
of a pointer insignificant.  Perhaps worth investigating at the
VM level.  I don't like this idea much either though.

Of course this still doesn't solve the problem that the OS
structures allocated by SWT may have different sizes and
layouts.  We could perhaps do away with this problem by
making the OS structure wrapper classes more intelligent.
At the very least, we could make the SIZEOF members
"smart".  The JNI memmove() implementations should deal
with all data layout issues.  [Note in places where we blindly
allocate a chunk of memory for an OS structure and poke
values into it, we'd have to create real wrapper classes instead.]

Smarter SIZEOF
-- Instead of:
static final int SIZEOF = xx;
-- Use
static final int SIZEOF = OS.sizeofMyStruct();
The JNI binding for OS.sizeofMyStruct() would just
return sizeof(MyStruct);

Jeff.

----- Original Message ----- 
From: "Havoc Pennington" <hp@xxxxxxxxxx>
To: <platform-swt-dev@xxxxxxxxxxx>
Sent: Monday, December 10, 2001 8:28 PM
Subject: Re: [platform-swt-dev] GTK in CVS


> 
> Steve_Northover@xxxxxxx writes: 
> > We could intruduce a bogus wrapper class for "int" (and watch
> > performance go out the window), write our own preprocessor
> > (I believe Sun forbids this) or split a stream and change all
> > "int" to "long" (this is awful too, no Java IDE properly supports
> > code fragments - there isn't even #ifdef - so it'd be a copy of
> > the current work, yet another SWT platform).  Nothing is nice.
> 
> Is there any evidence that just using Java long would cause a
> performance problem on ia32? You could use long all the time on all
> platforms, I would expect that even if it impacts performance
> noticeably (doubtful), time would be better spent optimizing
> algorithms elsewhere than maintaining two SWT streams.
> 
> Using long breaks the memmove()-to-read-struct-fields trick, but that
> trick is already broken due to bitfields and such in the C code, plus
> it depends on undefined/unspecified C compiler behavior and seems a
> bit intimate with the Java spec as well. The trick is also hard to
> port to GTK 2, because we rearranged the structs, and is not
> particularly efficient.
> 
> In GTK 2 the need to read struct fields should be quite rare, many
> accessor functions were added, and just a _teeny bit_ of native glue
> code when we have missing accessors would let you write legal C/Java
> instead of being in the land of unportable/undefined/unspecified.
> 
> > Question:  What do other strongly typed languages do?
> 
> Some languages have a "boxed" type that represents a native pointer, I
> believe. You can "box" and "unbox" native pointers from that type.
> 
> So why not use Java's "long" type for that purpose?
> 
> I am not much of a Java person, so take all this with a grain of salt.
> 
> I'm sure Jeffrey has good insights based on java-gnome.
> 
> Havoc
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>