Moving to pointer-sized GType?

[Alex Larsson <alexl redhat com>]

In GObject, the new Object system in Gtk+ 2, we are thinking of changing 
the GType type (replacement for GtkType) so that sizeof(GType) == 
sizeof(gpointer). GType is currently an uint which is 32 bit, so this 
change will affect all architectures where pointers are 64 bit.

The reason for this change is performance. When going from a 32bit GType 
to the data about the type we need to do a lookup in a data structure, 
and since this structure can change there has to be locks around it to be 
threadsafe. This unfortunately means that all type operations (including 
type-checks and type-checking casts) have locks in them.

Going to a pointer sized type lets us store the pointer in the GType, 
thereby giving a significant performance increase.

The change will be fully source compatible for code that correctly uses 
GType, but unfortunately there are some places in our codebases that use 
uint instead of GType/GtkType to store/handle types, and these will break 
on 64bit architectures (warning + segfault), but silently work on 32bit 
architectures.

Most of the bugs are of the type:
guint 
message_window_get_type (void)
{
  static guint mw_type = 0;

or:
GtkType
gimp_channel_list_view_get_type (void)
{
  static guint view_type = 0;

These can all be found by eliminating all appearances of guint in the 
output of 'find -name "*.c" | xargs grep -C2 _get_type', and we have done 
so for Gtk+, Gimp and gnome-libs. But the possiblility exists that some 
code stores GtkTypes in 32bit integers in some other fashion.

Doing this change will almost certainly cause some apps to segfault on 
64bit while working on 32bit until all our apps are fixed. 

We (the Gtk+ team) are interested in the opinion of developers (especially 
on 64bit systems) on this change. Do you think it is worth it? Do you know of any 
code that stores GtkTypes in uints currently?

/ Alex